Feature request: change the permissions of generated files

[ebaumgartner]

When I have umask set to 002, most npm build tools produce files whose permissions are set to 664. esbuild is producing files with 644, as if my umask were set to 022.

Example, using lessc to illustrate what other build tools do.

$ umask 022
$ npx lessc source.less out.css
$ npx esbuild source.jsx --bundle --outfile=out.js

  out.js  577.9kb

⚡ Done in 31ms
$ ls -l out*
-rw-r--r--  1 eric  staff      21 Aug  4 12:26 out.css
-rw-r--r--  1 eric  staff  591804 Aug  4 12:26 out.js

This is correct. Both lessc and esbuild generate files with 644 permissions when umask is 022.

Now let's look at umask 002.

$ rm out*
$ umask 002
$ npx lessc source.less out.css
$ npx esbuild source.jsx --bundle --outfile=out.js

  out.js  577.9kb

⚡ Done in 36ms
$ ls -l out*
-rw-rw-r--  1 eric  staff      21 Aug  4 12:27 out.css
-rw-r--r--  1 eric  staff  591804 Aug  4 12:27 out.js

With umask 002, the esbuild-generated file does not set the group write bit. For comparison, the less-generated file does.

I can work around this via chmod, but I think it would be nice if esbuild respected umask from the start.

For context, this leads to issues where two developers are deploying code to a server via different ssh accounts. Normally if these accounts belong to the same group and use umask 002, all the files generated via the deployment are writable by the group. This issue means that after developer A deploys, developer B can't deploy because they lack the permission to delete/change the esbuild-generated files developer A's deployment created.

[evanw]

I'm confused. I'm unfamiliar with umask but from reading the documentation it appears to only be a way to disable the setting of certain permission bits for the programs that you run. So everything already seems to be working correctly regarding umask? When you set umask 022 you are disabling the write bit for the "group" and "others" classes. And the write bits are indeed disabled, as you described yourself. When you set the umask to 002 you are no longer disabling the write bit for the "group" class. But that doesn't necessarily mean that the write bit is now enabled since umask doesn't have an "enabling" feature, just a "disabling" feature. For example, setting the group bit to 0 also means not disabling the execute bit, but that doesn't necessarily mean that every file you create will now be executable. It's not surprising that umask is already working correctly since it's implemented by the OS itself.

So it sounds to me like umask is actually irrelevant here. You seem to be just asking for esbuild's default permissions to be changed from 644 to 664. Is that correct? Or perhaps esbuild's default permissions should be changed from 644 to 666 to match the default behavior of fs.writeFileSync, since that's probably what most JavaScript-based tools are using.

[ebaumgartner]

So it sounds to me like umask is actually irrelevant here. You seem to be just asking for esbuild's default permissions to be changed from 644 to 664. Is that correct? Or perhaps esbuild's default permissions should be changed from 644 to 666 to match the default behavior of fs.writeFileSync, since that's probably what most JavaScript-based tools are using.

Yes, I think changing permissions would address the issue I'm seeing.

umask is relevant in that this edge case is tied to a particular value (umask 002). But I agree that there's nothing specific to umask that esbuild should do, since umask is applied by the system.

I think you're right that the way to address the issue would be to change the permission parameter passed in various ioutil.WriteFile calls (I think that's where this is happening) from 644 to probably 666, and then assume that the user's umask will knock those permissions down to appropriate values.

Thanks for looking into this! esbuild is awesome.