You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If all items in a Parcel bundle can be optimized to other bundles, the file generated by Parcel for that bundle is empty (and so is its source map).
NOTE: This is similar to #7412, but rather than everything being tree-shaken away, it is optimized into other locations and leaves behind empty files where some of the sources would have originally been.
No empty files should be generated by the build process ("empty" meaning either there is nothing, there is only comments, or (in the case of source maps) there are no sources or sourcesContent specified in the file).
😯 Current Behavior
Empty files are generated for JavaScript modules whose code either was unused or was able to be placed elsewhere in the generated files. The empty .js files include only a comment linking them to their source map file, but the associated .js.map file has no values for sources or sourcesContent (both are empty arrays). There are no errors during the build.
💁 Possible Solution
I don't know exactly what's causing this, so I'm not sure how you would go about fixing it, but here's a suggestion for one way you could fix it:
After the build process is complete, check each generated file for "emptiness". If a file has only a comment linking it to a source map and the source map has no values for sources or sourcesContent, consider the file and its source map "empty".
If a file and its source map are considered "empty", delete both files.
Alternatively, you could only create an output file for a particular file/bundle if that file/bundle still has contents after the tree-shaking and optimization processes and the contents are not just a link to the source map. This is above my head from a technical standpoint because I don't know how these two things are implemented in Parcel or when Parcel creates the output files, but I imagine a solution along these lines would probably be better than my other suggestion (less wasted resources since the "empty" files are never create in the first place rather than being created and then deleted).
🔦 Context
I was actually trying to test something else to get a better understanding of how Parcel works, so my test example is somewhat contrived, but an example where this issue may crop up is if a project contains a file full of constant variables. If some of these constants are used in only one or two other places in the project and others are unused (and will therefore be removed by the tree-shaking process), then I would expect an empty file to be generated for the file that originally contained the constants (or for the bundle that file was included in, assuming everything else in the bundle can also be optimized or tree-shaken away) based on the behavior I've seen.
To reproduce the behavior, add the package.json file from above into the same directory as index.html, then run npm i and npm run build to install Parcel and run a Parcel build. The resulting files in the dist directory should include some .js and .js.map files that meet the definition of "empty" given above in the suggested solution.
When I did this myself, the default exports from script.js and scripts/script2.js get moved into the final <script> tag in index.html (where they are imported and used), and the final export in scripts/script2.js (export const unused = "unused") is removed by tree-shaking, so I ended up with dist/index.html that looks like this:
and a handful of "empty" files (dist/index.616f4580.js and dist/index.957d38bf.js, each of which only contain comments linking them to their source maps, dist/index.616f4580.js.map and dist/index.957d38bf.js.map, neither of which have any values in their sources or sourcesContent properties). It is worth noting that dist/index.html links both generated script files, despite them being empty. I did not handle this in either of my suggested solutions, but it does need to be taken into account, otherwise, the HTML encounter an error when it tries to load scripts that don't exist.
🌍 Your Environment
Software
Version(s)
Parcel
2.2.1
Node
v16.13.2
npm/Yarn
npm 8.1.2
Operating System
Windows 10
The text was updated successfully, but these errors were encountered:
🐛 bug report
If all items in a Parcel bundle can be optimized to other bundles, the file generated by Parcel for that bundle is empty (and so is its source map).
NOTE: This is similar to #7412, but rather than everything being tree-shaken away, it is optimized into other locations and leaves behind empty files where some of the sources would have originally been.
🎛 Configuration (.babelrc, package.json, cli command)
package.json
(no other config files):🤔 Expected Behavior
No empty files should be generated by the build process ("empty" meaning either there is nothing, there is only comments, or (in the case of source maps) there are no
sources
orsourcesContent
specified in the file).😯 Current Behavior
Empty files are generated for JavaScript modules whose code either was unused or was able to be placed elsewhere in the generated files. The empty
.js
files include only a comment linking them to their source map file, but the associated.js.map
file has no values forsources
orsourcesContent
(both are empty arrays). There are no errors during the build.💁 Possible Solution
I don't know exactly what's causing this, so I'm not sure how you would go about fixing it, but here's a suggestion for one way you could fix it:
sources
orsourcesContent
, consider the file and its source map "empty".Alternatively, you could only create an output file for a particular file/bundle if that file/bundle still has contents after the tree-shaking and optimization processes and the contents are not just a link to the source map. This is above my head from a technical standpoint because I don't know how these two things are implemented in Parcel or when Parcel creates the output files, but I imagine a solution along these lines would probably be better than my other suggestion (less wasted resources since the "empty" files are never create in the first place rather than being created and then deleted).
🔦 Context
I was actually trying to test something else to get a better understanding of how Parcel works, so my test example is somewhat contrived, but an example where this issue may crop up is if a project contains a file full of constant variables. If some of these constants are used in only one or two other places in the project and others are unused (and will therefore be removed by the tree-shaking process), then I would expect an empty file to be generated for the file that originally contained the constants (or for the bundle that file was included in, assuming everything else in the bundle can also be optimized or tree-shaken away) based on the behavior I've seen.
💻 Code Sample
index.html
script.js
scripts/script2.js
To reproduce the behavior, add the
package.json
file from above into the same directory asindex.html
, then runnpm i
andnpm run build
to install Parcel and run a Parcel build. The resulting files in thedist
directory should include some.js
and.js.map
files that meet the definition of "empty" given above in the suggested solution.When I did this myself, the default exports from
script.js
andscripts/script2.js
get moved into the final<script>
tag inindex.html
(where they are imported and used), and the final export inscripts/script2.js
(export const unused = "unused"
) is removed by tree-shaking, so I ended up withdist/index.html
that looks like this:and a handful of "empty" files (
dist/index.616f4580.js
anddist/index.957d38bf.js
, each of which only contain comments linking them to their source maps,dist/index.616f4580.js.map
anddist/index.957d38bf.js.map
, neither of which have any values in theirsources
orsourcesContent
properties). It is worth noting thatdist/index.html
links both generated script files, despite them being empty. I did not handle this in either of my suggested solutions, but it does need to be taken into account, otherwise, the HTML encounter an error when it tries to load scripts that don't exist.🌍 Your Environment
The text was updated successfully, but these errors were encountered: