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

Babel CLI: --out-dir runs into permissions errors on second compile #7186

Closed
DinsmoreDesign opened this Issue Jan 9, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@DinsmoreDesign

DinsmoreDesign commented Jan 9, 2018

Relevant package.json Config

{
    "devDependencies": {
        "babel-cli": "^6.26.0",
        "babel-minify": "^0.2.0",
        "babel-preset-env": "^1.6.0"
    },
    "scripts": {
        "build-components": "babel Scripts/Components --out-file Scripts/Compiled/components.js",
        "build-pages": "babel Scripts/Pages --out-dir Scripts/Compiled/Pages",
        "watch-components": "babel Scripts/Components -w --out-file Scripts/Compiled/components.js",
        "watch-pages": "babel Scripts/Pages -w --out-dir Scripts/Compiled/Pages",
        "build-js": "npm run build-components && npm run build-pages"
    }
}

.babelrc Config

{
    "presets": [
        [
	    "env",
	        {
		    "modules": false,
		    "targets": {
		        "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
		    }
		}
	],
	"minify"
    ]
}

Example input at 'Scripts/Pages/Example.Vue.js'

Vue.use(VeeValidate);

var app = new Vue({
    el: "#stsApp",
    mixins: [rootPath, routesData, branding, notificationData],
    data() {
        return {
            serverData: window._View__Model,
            navLinks: [
                { url: this.routes.logout, name: 'Logout', description: 'Logout of the application', isActive: false }
            ]
        }
    }
});

Expected Behavior

After running npm run build-pages or npm run watch-pages, the file should compile from 'Scripts/Pages/Example.Vue.js' and output a minified ES5 file to 'Scripts/Compiled/Pages/Example.Vue.js', whether there's an existing file or not.

Current Behavior

Running the NPM scripts, this works if the folder is empty, but will fail to overwrite an existing file. The following outputs to the terminal if there is an existing file in the directory Babel outputs to, however, this works just fine when compiling to a single file, when I run the build/watch components commands:

> babel Scripts/Pages --out-dir Scripts/Compiled/Pages
Error: EPERM: operation not permitted, open 'D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\Scripts\Compiled\Pages\Index.Vue.js'
at Error (native)
at Object.fs.openSync (fs.js:584:18)
at fs.writeFileSync (fs.js:1224:33)
at outputFileSync (D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\node_modules\output-file-sync\index.js:45:3)
at write (D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\node_modules\babel-cli\lib\babel\dir.js:33:5)
at handleFile (D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\node_modules\babel-cli\lib\babel\dir.js:43:7)
at D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\node_modules\babel-cli\lib\babel\dir.js:61:9
at Array.forEach (native)
at handle (D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\node_modules\babel-cli\lib\babel\dir.js:59:29)
at Array.forEach (native)
npm ERR! Windows_NT 10.0.15063
npm ERR! argv "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Web\\External\\Node.exe" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Enterprise\\Web\\External\\node_modules\\npm\\bin\\npm-cli.js" "run" "build-pages" "--color=always"
npm ERR! node v5.4.1
npm ERR! npm  v3.3.4
npm ERR! code ELIFECYCLE
npm ERR! STS-VueApp@1.0.0 build-pages: `babel Scripts/Pages --out-dir Scripts/Compiled/Pages`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the STS-VueApp@1.0.0 build-pages script 'babel Scripts/Pages --out-dir Scripts/Compiled/Pages'.
npm ERR! This is most likely a problem with the STS-VueApp package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     babel Scripts/Pages --out-dir Scripts/Compiled/Pages
npm ERR! You can get their info via:
npm ERR!     npm owner ls STS-VueApp
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     D:\Projects\PasswordReset\Trunk\STS.PasswordReset.Web\npm-debug.log
Process terminated with code 1.

Context

This works perfectly fine the first time I compile, but running the command again, or auto-compiling with watch fails if I don't manually delete the file in the folder, which is a very poor experience.

I'm building this within Visual Studio and using the Task Runner Explorer package to run my commands (though it still fails from PowerShell, or running it as a build command within the project). The plugin runs 'npm run build-js' on build and 'npm run watch-components' and 'npm run watch-pages' afterwards to watch for any changes. 'npm run watch-pages' fails every time, as does 'npm run build-pages' if the files it outputs to already exist. The only solution I've found so far is to delete the 'Scripts/Compiled/Pages' folder (or the individual file I need to compile to) every time I make a change to a file within 'Scripts/Pages', which defeats the purpose of the watch command and is generally just annoying to have to do every time, especially when I'm doing a lot of file changes. Both build commands for components work every time and will overwrite the old file without issue.

I thought maybe it was something having to do with the files not being included in my project, because I get a similar error from the component builds if my 'Scripts/Compiled' folder isn't included in the project, but including 'Scripts/Compiled/Pages' still gives me the same error and including the actual output file, ie: 'Scripts/Compiled/Pages/Example.Vue.js' doesn't fix it either.

Your Environment

| Babel | 6.26.0
| node | 6.11.2
| npm | 5.6.0
| OS | Windows 10 Enterprise
| Visual Studio | Enterprise 2017
| ASP.NET MVC | 5

@babel-bot

This comment has been minimized.

Show comment
Hide comment
@babel-bot

babel-bot Jan 9, 2018

Collaborator

Hey @DinsmoreDesign! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

Collaborator

babel-bot commented Jan 9, 2018

Hey @DinsmoreDesign! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

@loganfsmyth

This comment has been minimized.

Show comment
Hide comment
@loganfsmyth

loganfsmyth Jan 9, 2018

Member

This sounds like a painful bug, but I'm afraid I also have no idea what would be causing it. If you're running --watch and it works the first time, it should be working the second time too. It sounds like your machine might have some kind of permission issue, but I don't know why that would be.

Member

loganfsmyth commented Jan 9, 2018

This sounds like a painful bug, but I'm afraid I also have no idea what would be causing it. If you're running --watch and it works the first time, it should be working the second time too. It sounds like your machine might have some kind of permission issue, but I don't know why that would be.

@DinsmoreDesign

This comment has been minimized.

Show comment
Hide comment
@DinsmoreDesign

DinsmoreDesign Jan 9, 2018

@loganfsmyth Thanks for the reply! I'm at a loss, as well. To make things even more strange... I seem to be able to compile using --out-dir just fine if I'm using a "Local Workspace" within Visual Studio, but using a "Server Workspace" produces the permissions error if the file already exists. Once again though, this error doesn't surface itself if I'm using --out-file in either workspace version. I guess the solution for now is to just use Local Workspaces for all my projects using Babel, but I was purposely using Server as it gave me performance benefits when connecting to TFS. The only issue I see arising with this is I believe that "Local Workspaces" are a newer option to Visual Studio and someone running an older version on my team may run into the same issue.

I was thinking maybe it was a file-specific permission error... maybe the output of --out-dir is giving different permissions in Windows to files, but the output files from --out-dir and --out-file seem to be the same! Arg, frustrating, indeed...!

DinsmoreDesign commented Jan 9, 2018

@loganfsmyth Thanks for the reply! I'm at a loss, as well. To make things even more strange... I seem to be able to compile using --out-dir just fine if I'm using a "Local Workspace" within Visual Studio, but using a "Server Workspace" produces the permissions error if the file already exists. Once again though, this error doesn't surface itself if I'm using --out-file in either workspace version. I guess the solution for now is to just use Local Workspaces for all my projects using Babel, but I was purposely using Server as it gave me performance benefits when connecting to TFS. The only issue I see arising with this is I believe that "Local Workspaces" are a newer option to Visual Studio and someone running an older version on my team may run into the same issue.

I was thinking maybe it was a file-specific permission error... maybe the output of --out-dir is giving different permissions in Windows to files, but the output files from --out-dir and --out-file seem to be the same! Arg, frustrating, indeed...!

@nicolo-ribaudo

This comment has been minimized.

Show comment
Hide comment
@nicolo-ribaudo

nicolo-ribaudo Jan 9, 2018

Member

I don't remeber how Windows works, but is there a way to see which users/roles can write into a folder? Maybe it could help with debugging this bug.

Member

nicolo-ribaudo commented Jan 9, 2018

I don't remeber how Windows works, but is there a way to see which users/roles can write into a folder? Maybe it could help with debugging this bug.

@simonbuchan

This comment has been minimized.

Show comment
Hide comment
@simonbuchan

simonbuchan Jan 22, 2018

This sounds like VS has the file open without the appropriate file sharing mode, which is a VS bug (since it shouldn't be assuming files will not be edited / deleted out from under it!)

Essentially, in Windows, when you open a file you specify what access you want for the new file handle, and what permissions you are OK with others having while you have the handle open, e.g. read and write, but not delete - this is called the "sharing mode". When node.exe tries to open a file and gets a sharing mode violation it surfaces it as EPERM (which isn't ideal, but it's the closest match)

graceful-fs will handle many cases where this is a transient issue (e.g. two processes just happen to write at the same time), but that's not likely here.

simonbuchan commented Jan 22, 2018

This sounds like VS has the file open without the appropriate file sharing mode, which is a VS bug (since it shouldn't be assuming files will not be edited / deleted out from under it!)

Essentially, in Windows, when you open a file you specify what access you want for the new file handle, and what permissions you are OK with others having while you have the handle open, e.g. read and write, but not delete - this is called the "sharing mode". When node.exe tries to open a file and gets a sharing mode violation it surfaces it as EPERM (which isn't ideal, but it's the closest match)

graceful-fs will handle many cases where this is a transient issue (e.g. two processes just happen to write at the same time), but that's not likely here.

@loganfsmyth loganfsmyth closed this Mar 5, 2018

@lock lock bot added the outdated label Jun 4, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Jun 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.