For questions please post on Stack Overflow and use the 'webpack' tag (http://stackoverflow.com/tags/webpack).
@lakshsyal123 That looks more like an obfuscator than minifier. I'm not able to identify which one off the top of my head, mostly because they look rather similar to me in unreadableness. I'd find an obfuscation you like and find a plugin like this: https://github.com/javascript-obfuscator/webpack-obfuscator
@fahadm I made an answer for you
@shehi you can leave the room by clicking on the vertical sliders button to the left of your profile picture in the top right. Here's an image of the button above, click on the second to last to leave.
t)
If you mean do asset stuff in Webpack 4 you can use equivalent loaders. The documentation goes over it but to repeat it you can use file-loader: see this and this. You have to install it like you would any other dependency.
The replacement rule might look like this:
The replacement rule might look like this:
{
test: /data\/json\/.+\.json$/
loader: 'file-loader',
options: {
// Look at https://webpack.js.org/configuration/output/#template-strings to see additional template strings.
name: '[path][name].[hash:6][ext]'
}
}
I've also edited my Stack Overflow answer to include that and suggested a Webpack 4 tag.
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.