-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long variable names #29
Comments
Does the identifier it get minified? From the snippet you posted it looks like it. Names minified / mangled are between 1 and two chars. |
We recently launched and it has been much easier to find bugs with the code unminified. It isn't an ideal production environment, but it's been the best choice for now. As things become more stable I may use uglify again. |
@jacwright I don't suppose you ever stumbled upon a solution to this? I assume it's just how webpack does things, but it does make things rather hard to follow. |
It's about webpack and how it creates variables internally. Debugging should really take place with source maps enabled; shipping with minification in place to mangle the names. I think this issue can be closed as won't fix for the loader. |
It it not how webpack creates variables internally. Webpack doesn't create variables in svelte code. Everywhere else in my compiled code the ES6 compiler short import names. This is because svelte uses the I looked into it more this morning and found the reason this occurs is because the ES6 code being generated for helpers is:
And if I change the end of this line https://github.com/sveltejs/svelte-loader/blob/master/index.js#L29 to
and the long variables with pathnames from my machine go away. This could be a security/privacy issue if compiled (non-compressed) code is stored in git, such as libraries of svelte components. Usually you don't uglify libraries, since the end product will do that in production. I'm not sure why With the change made in my PR the resulting variable is now:
instead of
|
Using the full local path exposes security/privacy issues when svelte components are provided as NPM modules. The compiled code includes the path information in the variable names. This also bloats the code, which isn't as much an issue since it eventually gets compressed with libraries such as uglify. The bigger issue is the local path information being publicized this way. Are there any issues with removing `require.resolve`? Svelte should be available without it, but perhaps there are edge cases I cannot think of. See sveltejs#29
This might be something with my webpack configuration rather than a problem with the loader, but I thought I would check.
I have an existing app I am wanting to migrate to using svelte but the components are bloating my JavaScript file. I am not using Uglify currently for certain reasons and would like to find out if this could be fixed easily.
A simple
<h1>Hello {{name}}!</h1>
component looks like this:You can see the export is named
__WEBPACK_IMPORTED_MODULE_0__Users_jacob_wright_Personal_Projects_dabble_dabble_node_modules_svelte_shared_js__
and really bloats the JavaScript. Does anyone know how this might be reduced or if I have a setting causing this? I don't see it anywhere else in my file.The text was updated successfully, but these errors were encountered: