For questions please post on Stack Overflow and use the 'webpack' tag (http://stackoverflow.com/tags/webpack).
Thanks*
@DavidArchibald : Thank you the information about obfuscator I always saw that obfuscator change variables like
_0xef14 So I didn't think that they used obfuscator. Do you think we can tell obfuscator to not convert anything like _0xef14 as browser sometime things that this is virus code.
@lakshsyal123 different obfuscators have different strategies, some might simply change it to be
First and foremost I'd suggest not obfuscating your code unless you have a reason to do so already. Generally a good minifier will shorten the file length more than an obfuscator because the obfuscator also intends to make the code complicated to reverse engineer. This sort of thing lends itself towards browser suspicion but you'll probably have to play around with the options to see what fixes it. Specifically for preventing hexadecimal name mangling, that's really up to the individual obfuscator and its options. The first obfuscator I found under the keywords "Javascript Obfuscator" has exactly the option you're looking for here: https://github.com/javascript-obfuscator/javascript-obfuscator/tree/52358aba2659c1fb16c3594efee8e3d9b74b1e3a#identifiernamesgenerator
a, b, c, etc. What you shared could theoretically label itself a minifier as the lines sometimes are blurred.First and foremost I'd suggest not obfuscating your code unless you have a reason to do so already. Generally a good minifier will shorten the file length more than an obfuscator because the obfuscator also intends to make the code complicated to reverse engineer. This sort of thing lends itself towards browser suspicion but you'll probably have to play around with the options to see what fixes it. Specifically for preventing hexadecimal name mangling, that's really up to the individual obfuscator and its options. The first obfuscator I found under the keywords "Javascript Obfuscator" has exactly the option you're looking for here: https://github.com/javascript-obfuscator/javascript-obfuscator/tree/52358aba2659c1fb16c3594efee8e3d9b74b1e3a#identifiernamesgenerator
I am building a 3rd party script that would inject to other users website and I don't want my compitators to copy the logic easily so I want to use obfuscator. I'll do play with this Javascript Obfuscator and if I get anyfurther question I'll come back to ask. Thank you very much for all your answers it was really helpful for me @DavidArchibald :)
There is a problem
How to hide the output file to hide the server address during lazy loading
oh would you just like the stdout output to be cleaner and shorter?
It almost certainly does not do anything so amazing that your "competitors" would be advantaged by stealing it
and if it does you should perform that operation on the server instead
ideally behind authentication, because your algorithm is so special
(it probably isn't)
(actually that's for like 1%, the remaining 98.9% should also ship sourcemaps)
Is there any opt for it in webpack,
is that actually bundled into the code in any way...? That seems to just be referring to an uglify loader anyways. I don't think anything like that would be bundled in production mode (development mode definitely has comments saying where the file came from for ease of use though)
I'm asking because I honestly cannot see how developers seeing locations of their files on a system they can ostensibly control would be a problem unless it's bundled and clients could see it on code execution or something (even that is rather tenuous)
It looks like the output of
npm install
which is doing a webpack build during postinstall, which... I can't think of a reason that would ever be a good idea or make sense
like a github ci or similar
but instead of hooking postinstall, you'd have finer-grained control over what's happening by invoking webpack in the Jenkins build script
yup that's true... regardless if some client or some non-trusted dev has access to your ci they presumably have direct access to your code and so you have much bigger problems. I honestly cannot think of why someone would have access to automated build info and not be privvy to the source code.
hi all, i'm getting a one time warning after upgrading some dependencies, not seeing any issues for it as its a warning, and the app is working fine, but wondering what this means?
[webpack.cache.PackFileCacheStrategy/webpack.FileSystemInfo] Resolving 'lodash/package.json' in /Users/kelly/tock/admin/clowncar/node_modules/babel-plugin-lodash/lib for build dependencies doesn't lead to expected result '/Users/kelly/tock/admin/clowncar/node_modules/lodash/package.json', but to '/Users/kelly/tock/admin/clowncar/node_modules/babel-plugin-lodash/node_modules/lodash/package.json' instead. Resolving dependencies are ignored for this path.I updated babel-loader with a minor bump, and webpack as well, and babel-core,
babel-core - 7.13.15
babel-loader - 8.2.2
webpack - 5.31.0
after I get this, stop, then start it, it is no longer shown, guessing because its cached.
I’d begin investigation of babel-plugin-lodash and the lodash module. It looks like npm and/or Webpack expect the npm modules to be flat; e.g. directly within node_modules, but it finds it within node_modules/babel-plugin-lodash/node_modules/lodash. This might just because of the update not flattening the modules right. You should first try deleting your node_modules and reinstalling then then trying again than looking at the dependency graph for lodash to see if it’s in an inconsistent state or something.
I'm having a problem with webpack.DefinePlugin. It's not defining anything.
Webpack version: 5.31.2plugins: [
new webpack.DefinePlugin({ ASSET_PATH: "testtest" }),
...
]
Then in my webapp, I check to see if window.ASSET_PATH is defined. It's not. Any clue what's going on? Is DefinePlugin broken in webpack 5?
If you'd have read the documentation you'd see that DefinePlugin does a direct "text replacement". It doesn't actually create a value on window. See: https://webpack.js.org/plugins/define-plugin/. I just tried it and it worked just fine for me. Though I believe you'll want to
JSON.stringify it like so: new webpack.DefinePlugin({ "window.ASSET_PATH": JSON.stringify("testtest") }) -- you may be mixing up the error with texttext being a literal and DefinePlugin "not working"
otherwise it may be an error and I'd encourage you to share a minimum repo etc.
Yup. JSON.stringify is a bit more broad as it'll escape quotes in the text but yes that will work. Also it depends on where you're going with this "ASSET_PATH" but you may be more interested in Asset Modules if you're trying to get the path of assets.