Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Parcel creates empty .js and .js.map files during build #7646

Closed
scm04 opened this issue Feb 3, 2022 · 1 comment
Closed

Parcel creates empty .js and .js.map files during build #7646

scm04 opened this issue Feb 3, 2022 · 1 comment
Labels
Stale Inactive issues

Comments

@scm04
Copy link

scm04 commented Feb 3, 2022 •
edited
Loading

🐛 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):

{
	"name": "test",
	"version": "1.0.0",
	"description": "",
	"source": "index.html",
	"scripts": {
		"start": "parcel",
		"build": "parcel build"
	},
	"keywords": [],
	"author": "",
	"license": "ISC",
	"devDependencies": {
		"parcel": "^2.2.1"
	}
}

🤔 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 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.

💻 Code Sample

index.html

<!DOCTYPE html>
<html lang="en">
<head>
	<title>Parcel Build Test</title>
	<script src="script.js" type="module"></script>
	<script src="scripts/script2.js" type="module"></script>
	<script type="module">
		import print from './script.js'
		import message from './scripts/script2.js'
		print(message)
	</script>
</head>
<body>
</body>
</html>

script.js

export default function print(message) {
	console.log(message)
}

scripts/script2.js

export const message = "Hello"
export default message
export const unused = "unused"

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:

<!DOCTYPE html>
<html lang="en">
<head>
	<title>Parcel Build Test</title>
	<script src="/index.616f4580.js" type="module"></script>
	<script src="/index.957d38bf.js" type="module"></script>
	<script type="module">var l; l = "Hello", console.log(l);</script>
</head>
<body> </body>
</html>

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
@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

@github-actions github-actions bot added the Stale Inactive issues label Aug 3, 2022
@MoonLGH MoonLGH mentioned this issue Aug 16, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Stale Inactive issues
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@scm04