Comments (52)
@edm00se has discovered that this is resolved when setting {shell: true}
in the options, which we do in next
. This means that as soon as this lands, this issue will be fixed!
from cross-env.
There is not I'm afraid. I'm not sure how to solve the problem honestly. Suggestions and pull requests are welcome.
from cross-env.
By the way, reproducing this on Linux-based environments is also possible by using something like %npm_package_name%
. This is also replaced by $npm_package_name
, but not evaluated.
from cross-env.
@edm00se Right. It does work now. I probably forgot to build or something. Sorry.
from cross-env.
Could you try this out with cross-env@beta
in your project and let us know if it fixes things? I'm most uncertain about this issue, so I want to make sure it's resolved before officially releasing beta
. Thanks!
from cross-env.
Ok, so, to make sure I understand, you're saying that if you use cross-env-shell
it works, but it doesn't work with cross-env
?
from cross-env.
Yeah, I'm pretty sure this is part of why cross-env-shell
was created in the first place. Please use that. Thanks!
from cross-env.
This is definitely a bug. Any chance you could create a repository that reproduces this issue? Thanks!
from cross-env.
Actually a single package.json
file with the following content would make it:
{
"name": "my-nice-app",
"version": "1.0.0",
"scripts": {
"echo_name": "cross-env echo $npm_package_name"
},
"devDependencies": {
"cross-env": "^3.2.4"
}
}
and then run npm run echo_name
in Windows cmd, Cygwin or VSCode bash.
I would expect this to display my-nice-app
instead of %npm_package_name%
Additional info:
$ node -v
v6.9.1
$ npm -v
4.2.0
from cross-env.
Sorry, I was unable to reproduce. This works just fine:
~/Desktop
π $ git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
Cloning into 'cross-env-npm-env-vars'...
remote: Counting objects: 88, done.
remote: Compressing objects: 100% (69/69), done.
remote: Total 88 (delta 9), reused 88 (delta 9), pack-reused 0
Unpacking objects: 100% (88/88), done.
~/Desktop
π $ cd cross-env-npm-env-vars/
/Users/kdodds/Desktop/cross-env-npm-env-vars
~/Desktop/cross-env-npm-env-vars (master)
π $ npm install
[email protected] /Users/kdodds/Desktop/cross-env-npm-env-vars
βββ¬ [email protected]
βββ¬ [email protected]
β βββ¬ [email protected]
β β βββ [email protected]
β β βββ [email protected]
β βββ¬ [email protected]
β β βββ [email protected]
β βββ¬ [email protected]
β βββ [email protected]
βββ [email protected]
~/Desktop/cross-env-npm-env-vars (master)
π $ npm run echo_name
> [email protected] echo_name /Users/kdodds/Desktop/cross-env-npm-env-vars
> cross-env echo $npm_package_name
cross-env-npm-env-vars
~/Desktop/cross-env-npm-env-vars (master)
π $
Try it yourself:
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name
Note: This is why I ask for a repository that reproduces the issue. Because more often than not you'll find out that it's not related to cross-env
at all, but is something else entirely. Good luck figuring out what it is! :)
from cross-env.
Quick close... Your example (no more than just a package.json file) is failing on my side
from cross-env.
Your example (no more than just a package.json file) is failing on my side
Ok, thanks for letting me know. Unfortunately that doesn't really help us know how to solve the issue. Could you please dig a little deeper and get more information (or try to fix the issue)?
from cross-env.
I have encountered this same issue just now. @kentcdodds, I can confirm that your reproduction is also failing for me. I am running Windows 10, NPM 3.10.8, and NodeJS 6.8.1. I can reproduce the problem from both Git Bash and the Windows CMD.exe.
$ git clone https://github.com/kentcdodds/cross-env-npm-env-vars
Cloning into 'cross-env-npm-env-vars'...
remote: Counting objects: 88, done.
remote: Compressing objects: 100% (69/69), done.
remote: Total 88 (delta 9), reused 88 (delta 9), pack-reused 0
Unpacking objects: 100% (88/88), done.
Checking connectivity... done.
$ cd cross-env-npm-env-vars/
$ npm i
[email protected] C:\Users\wfaust\Documents\Development\cross-env-npm-env-vars
`-- [email protected]
+-- [email protected]
| +-- [email protected]
| | +-- [email protected]
| | `-- [email protected]
| +-- [email protected]
| | `-- [email protected]
| `-- [email protected]
| `-- [email protected]
`-- [email protected]
$ npm run echo_name
> [email protected] echo_name C:\Users\wfaust\Documents\Development\cross-env-npm-env-vars
> cross-env echo $npm_package_name
%npm_package_name%
I will investigate further and see if I can determine why this is happening.
from cross-env.
Thanks for the added confirmation @wolfgang42. Reopening.
from cross-env.
@cvillerm, you're also on Windows correct? This appears to be a windows-only issue.
from cross-env.
Actually, it seems to be any environment variable, not just ones defined outside of cross-env
. I see the same problem with this script:
"scripts": {
"echo_name": "cross-env testvar=foo echo $testvar"
}
which results in %testvar%
instead of the expected foo
.
This looks like it might be a bug in the cross-spawn
package, perhaps? The variable syntax is being converted by commandConvert()
, but I'm not sure at what point variable substitution is supposed to be happening.
from cross-env.
Happens here. Unfortunately it's not super simple, but the basic idea is that cross-env
simply removes all instances of setting environment variables and adds them to envVars
which is then used in the spawn call. In the case of npm_package_name
however, that variable should be pre-loaded into process.env
when cross-spawn starts, so it should already be included here.
Could you verify that it is included at that point and if it's not try to figure out why it's not in process.env
when cross-env
starts out. Because npm run
should be setting that.
from cross-env.
Yes, @cvillerm is on Windows.
This results in the following on Windows (with Windows cmd, CygWin bash or VSCode bash)...
I have verified that process.env.npm_package_name
is set, and that the correct value is in the env
variable by index.js:11.
from cross-env.
Actually...
> cross-env A=1 echo $A
%A%
> cross-env A=1 node -e "console.log(process.env.A)"
1
> echo echo %A% > echo.bat
> cross-env A=1 echo.bat
1
I'm not sure echo
can be trusted here.
from cross-env.
@hgwood You're looking at the wrong thingβthe environment variable is set, but not substituted in the arguments. Instead of process.env
you should be looking at process.argv
. Similarly, in your echo.bat
it's cmd.exe
doing the argument substitution from the environment variables.
from cross-env.
cross-env does not substitute variables for their value, it only converts the syntax from $a
to %a%
.
from cross-env.
from cross-env.
You are right. It does not make much sense. I have only been a contributor for a few days so I have looked at the history. cross-env was made to handle setting env vars, not reading them. Some support for reading them was introduced in #32, but it only works in very specific scenarios (I don't know which).
I have recently been working on improving this. See #86, #89, #90. I would assume #89 fixes the problem we are discussing, but I have just run a few tests and it looks like it does not. The first solution discussed in #90 would though.
from cross-env.
I've update the reproduction repo to use node -e
instead of echo
which is unreliable as noted :)
So, we all need to remember that cross-env
was never intended to replace environment variable references in the command with the value. Neither is cross-var
for that matter. Their job is to simply change the script to use the syntax compatible for the platform on which they run. Then spawn that script. From there, the OS takes care of things.
So now if you run this you should get the correct output:
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name
cross-env
is working as designed and supporting the use cases you should use it for.
from cross-env.
Thanks both for looking deeper into that. Obviously, this wasn't the result I was looking for and this confirms that this seems to be an acceptable limitation of this command for environment variables defined "outside of" cross-env in Windows, as this issue was about.
Although cross-var
is much less used than cross-env
, it worked fine with such npm package-based variable. I may have to look at that direction.
Thanks again
from cross-env.
Hmmm... I'm pretty confident that even without cross-env you would see the same result. This is just how things work unless I'm missing something...
from cross-env.
Ah, after looking more closely at the cross-var
implementation it appears that it's actually replacing the string values with the actual values rather than spawning the command with the values set in process.env
. I guess it's just a difference in perspective. Do you want to execute a script that would behave exactly the same as echo %npm_package_name%
or do you want to execute a script that replaces the value first? Ultimately, you should get the exact same result in any real-world scenario.
from cross-env.
The way I would like to use environment variables would be to use them as part of an npm script definition, not only within the executed script, for instance to create a docker image with a tag based on the name as defined in the package.json
file, e.g.:
"build_docker": "docker build -t $npm_package_name ."
from cross-env.
Yes, that should work with cross-env
. Have you tried it?
from cross-env.
It doesn't work (in Windows) as cross-env docker build -t $npm_package_name .
as it doesn't with the simpler example I provided in this issue with cross-env echo $npm_package_name
from cross-env.
At https://github.com/kentcdodds/cross-env/blob/master/src/command.js#L18, what about replacing:
command = isWin ? `%${match[1]}%` : `$${match[1]}`
by
command = process.env[match[1]];
This would work for environment variables set before cross-env is called. Being able to replace locally set variables would require using envVars
instead
from cross-env.
And by the way, using parent/child scripts can be a workaround to make it work without an update:
"scripts": {
"echo_name": "cross-env echo $npm_package_name",
"echo_name_parent": "cross-env npm run echo_name"
},
npm run echo_name_parent
will then work as expected. The same is true for more complex commands.
from cross-env.
Yeah, this is pretty odd. I definitely want to solve this issue. However I don't want to go with your proposed solution due to the unintended side-effects that could cause (there's no guarantee that replacing the variable with its value will even result in valid syntax). But let's figure out how to solve this issue.
from cross-env.
Yes, I agree that this needs to be fixed in a cleaner way ... and without breaking current unit tests
from cross-env.
Great ! Thanks for following this up.
from cross-env.
@cvillerm could you checkout next
and confirm it is fixed there? I have done a few test and it looks like it is not fixed, but I might be doing something wrong.
from cross-env.
@hgwood This looks to be working from my cloned copy of the next
branch. Is there a better test to run?
from cross-env.
I forgot to build first as well. π
from cross-env.
Thank you for verifying! I'm so glad this will be fixed soon!
from cross-env.
Sorry if I didn't answer before, but it takes me ages to run npm install
on a clone of cross-env and trying to run it locally doesn't work for me (src/bin/cross-env.js ...
). I am not sure what's wrong with it.
from cross-env.
Sorry, it's not the most straightforward thing to do to be honest. But I've updated the reproduction repo and it should work. Just do this (again):
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name
And hopefully it will work!
from cross-env.
I was referring to cloning the cross-env repository, checking out its "next" branch and running npm install
to install its own dependencies to test it locally (without referring to it from another test repo).
I anyway also have a problem installing your cross-env-npm-env-vars example, as referring to cross-env as kentcdodds/cross-env#next
as devDependency doesn't seem to work in my environment, while referring to the published version works fine. I am behind a proxy, but my environment is normally configured fine to work behind a proxy and I am used to it. Adding that I am developing in Windows is likely adding other constraints.
I am giving up but I am trusting that this will work when the next
version is published.
from cross-env.
@kentcdodds , I tested this beta version on Windows (git bash and WIndows cmd) with your test project (cross-env-npm-env-vars) and with one of my projects and this worked fine.
$ npm run echo_name
> [email protected] echo_name D:\Tmp\cross-env-npm-env-vars
> node node_modules/cross-env/dist/bin/cross-env.js echo $npm_package_name
cross-env-npm-env-vars
Thanks!
from cross-env.
It seems your version 5.0.1 is still published, with a number upper that beta 5.0.0-beta.0.
Is it possible to publish your fix on 5.0.1-beta.0 ? or to publish it without beta if it works correctly ?
Thanks
from cross-env.
Hmmm... 5.0.1 should have the fix. That's the latest version
from cross-env.
from cross-env.
Ok. Thanks for bringing it up. Could you dig a little further to see where the problem is and suggest a solution to fix it?
from cross-env.
In fact it only works if you define use shell option, because command in exec by node spawn and not a shell.
I've test the command
> cross-env echo $npm_package_name $npm_package_version
%npm_package_name% %npm_package_version%
I see in the code you send it to cross-swpan, that just do a child_process.spawn. And here, if your directly test cross-spwan like this:
const { spawn } = require('cross-spawn');
var child = spawn('echo', ['%PATH%'], { stdio: 'inherit' });
it returns only %PATH% without translation
and same for
const { spawn } = require('child_process');
spawn('echo', ['%PATH%']).on('error', function( err ){ throw err }
The reason it works when we do on a linux
> cross-env echo $npm_package_name $npm_package_version
PACKAGE-NAME 1.0.0
or on window
> cross-env echo %npm_package_name% %npm_package_version%
PACKAGE-NAME 1.0.0
is because the OS replace the value directly becore accession to your function. You can see it by logging commandArgs
var inside index.js and you will see the value are already transformed.
For me the only way to resolve it is commandConvert
function to replace $xxx by its value if available instead of %xxx% in windows case.
In this case you may need also to pass the getEnvVars
as parameter to see the newly added env vars, because they willl be available only new spawn.
from cross-env.
from cross-env.
@paztis Problem solved then?
from cross-env.
hey, sorry to crash the party, but there's still a problem with using cross-env-shell
, namely that slashes seem to always be replaced with backslashes on windows.
E.g.: cross-env-shell "echo /"
outputs \
.
Is there a way to tell cross-env-shell not to replace slashes or to escape certain slashes?
Using [email protected] on Windows 10 with node 8.4.0 and npm 5.3.0
from cross-env.
Note that cross-env-shell and actual substitution of variable only works with the $var syntax, not the %var% syntax, which only gets substituted on Windows.
from cross-env.
Related Issues (20)
- issue with nodejs in windows HOT 1
- PATH variable replacement on Windows envirement HOT 3
- No custom variable available without REACT_APP_ prefix HOT 1
- Passing url parameter on windows breaks HOT 1
- Processing variables on MacOS 10.15.2 only works with single quotes HOT 4
- cross-env should exit with non-zero code when terminated by Ctrl-C (SIGINT) HOT 5
- v7.0.1 leaves processes hanging on Windows HOT 1
- Cannot find module 'isexe' HOT 2
- Angular compilation problem HOT 1
- How to run cross-env from powershell in Windows? HOT 1
- Imports failing with "cannot locate symbol" error for wheels built on Ubuntu, deployed on aarch64 Android HOT 3
- More than 3 parent directories (..) in path ignored on Windows HOT 2
- Cross-env-shell in Windows via Npx doesn't handle multiple commands properly HOT 1
- Command causing cross-shell-env to fail silently HOT 2
- No cross-platform way of setting environment values containing spaces HOT 1
- cypress install no_proxy not working ? HOT 2
- Variables empty HOT 2
- The automated release is failing π¨
- Fresh Laravel v8.12 install, node.js - TypeError: commandConvert is not a function HOT 1
- cross-env is "finished" (now in maintenance mode) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cross-env.