Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 14 04:19
    webpack-bot labeled #13383
  • May 14 03:07
    webpack-bot labeled #13385
  • May 14 02:45
    webpack-bot labeled #13384
  • May 14 02:03
    webpack-bot labeled #13385
  • May 14 02:03
    dependabot[bot] labeled #13385
  • May 14 02:03
    dependabot[bot] opened #13385
  • May 14 02:03

    dependabot[bot] on npm_and_yarn

    chore(deps-dev): bump fork-ts-c… (compare)

  • May 14 02:02
    webpack-bot labeled #13374
  • May 14 02:02
    webpack-bot labeled #13384
  • May 14 02:02

    dependabot[bot] on npm_and_yarn

    chore(deps-dev): bump less-load… (compare)

  • May 14 02:02

    dependabot[bot] on npm_and_yarn

    chore(deps-dev): bump simple-gi… (compare)

  • May 14 02:02
    dependabot[bot] labeled #13384
  • May 14 02:02
    dependabot[bot] opened #13384
  • May 14 02:02
    webpack-bot labeled #13383
  • May 14 02:02
    dependabot[bot] labeled #13383
  • May 14 02:02
    dependabot[bot] opened #13383
  • May 13 09:47
    webpack-bot synchronize #7075
  • May 13 09:47

    webpack-bot on master

    chore(deps-dev): bump @types/no… Merge pull request #13376 from … (compare)

  • May 13 09:47

    webpack-bot on npm_and_yarn

    (compare)

  • May 13 09:47
    webpack-bot closed #13376
Luke Abby
@DavidArchibald
@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
image.png
@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.
Fahad Mansoor
@fahadm
Hey @DavidArchibald is it also possible to do jn webpack 4? ( Haven't migrated to webpack 5 ye
t)
Luke Abby
@DavidArchibald
To do jn? Could you explain the acronym.
Luke Abby
@DavidArchibald
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:
{
    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.
Fahad Mansoor
@fahadm
Thanka alot!
Thanks*
Lakshya
@lakshsyal123
@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.
Luke Abby
@DavidArchibald
consider approving my edit to your question (just to add webpack 4) and accepting my answer for other's clarity @fahadm
Luke Abby
@DavidArchibald
@lakshsyal123 different obfuscators have different strategies, some might simply change it to be 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
Lakshya
@lakshsyal123
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 :)
Luke Abby
@DavidArchibald
Well that's fair. I'll just warn you now though, no matter how much you obfuscate your program reversing it is basically be definition possible (as it has to run that code in the browser eventually)
Lakshya
@lakshsyal123
Okay, I'll check both cases as final outoput I want is that my users could get the best from my script.
cddsgtc
@cddsgtc
hello there
There is a problem
How to hide the output file to hide the server address during lazy loading
微信截图_20210409172824.png
Luke Abby
@DavidArchibald
What's the use case? I'd expect that you could deduce the server address regardless unless I'm misunderstanding.
oh would you just like the stdout output to be cleaner and shorter?
cddsgtc
@cddsgtc
replace that words with full internet address
James Bromwell
@thw0rted
Honestly, you almost certainly don't need to hide your code
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)
Luke Abby
@DavidArchibald
Yeah exactly that most likely
James Bromwell
@thw0rted
The correct amount of obfuscation for 99.9% of browser JS is to not ship sourcemaps
(actually that's for like 1%, the remaining 98.9% should also ship sourcemaps)
cddsgtc
@cddsgtc
that‘s my explain,but the boss don't think so.😭
Is there any opt for it in webpack,
James Bromwell
@thw0rted
I'm confused what you're trying to (further) obfuscate. Your image highlighted Webpack console output? Or is that in the browser console? (It shouldn't include a build pathname in runtime logging)
cddsgtc
@cddsgtc
That screenshot shows the static server path, that's not safe.
Luke Abby
@DavidArchibald
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)
James Bromwell
@thw0rted
yeah again, to be clear, is the screenshot of the command line when Webpack is running, or of the browser console when the (production) site is loaded by a client?
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
Luke Abby
@DavidArchibald
maybe an automated build setup?
like a github ci or similar
James Bromwell
@thw0rted
It does say it's running in Jenkins
but instead of hooking postinstall, you'd have finer-grained control over what's happening by invoking webpack in the Jenkins build script
Luke Abby
@DavidArchibald
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.
shehi
@shehi
Tried that @DavidArchibald . Has zero effect. I am on webclient, not some special native client if there is any
Luke Abby
@DavidArchibald
That’s strange, sorry I’m not an admin so I’m unable to kick you
Kelly
@kelly-tock

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.

Luke Abby
@DavidArchibald
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.