I am working on my third project where my boss has asked me to add a build stage to the server-side portion of our app that obfusicates and minifies the app into a single file. the reasons being that we are contracted to do development for our clients, where we'll be running our code on their hardware (some VPS, some on-prem) and he doesn't want them to have access to our source code so that they can't reverse-engineer it and steal our IP (of which we honestly don't have much of value... most of our "magic" is just open-source npm packages). not to mention that uglify doesn't do much to stop a reasonably dedicated reverse-engineer.the problem here is, as many of you are familiar, node.js is really not designed to be webpacked in the way that popular browser frameworks and libraries are. many of them use native modules (sharp), some dymanically require() files expecting a specific folder structure (threads.js), others rely on node module system quirks which webpack doesn't play nice with (typeorm).twice now, I've been able to pull it off, with the caveat of making substantial changes to the original source code. as our development team gets better and our apps become more complex, bundling our server-side code becomes harder and harder. I'm currently struggling on the third app I've been asked to webpack, and I've managed to work around the native modules (shoutout to webpack-node-externals and generate-package-json-webpack-plugin), typeorm's exploitation of the node.js module system makes it really crippled under the webpack runtime and I'm not sure how much further I can take it without crippling the DX of our app.I guess my question is, is webpacking a node.js app a reasonable thing to ask, how often is this actually done in the industry, and is there some "one weird trick" I'm missing to make this work?
Submitted August 29, 2020 at 07:52PM by 800_db_cloud
No comments:
Post a Comment