Comments (18)
Good point, I haven't used cross-env
along with cross-var
yet, but I can see how that would be a problem. I'm currently working on a separate branch that restructures the code and adds unit tests, but I can look into your PRs into the existing code base and then make sure they get applied to the restructured code too. I'll check out your stuff tonight... thanks for your feedback!
from cross-var.
I'd like to briefly consider another delimiter. Any other suggestions?
How about printf
-style? Assume that every occurence of :
in a variable value is a delimiter. If you want it to be interpreted as a literal :
, then escape it like \\:
(or ::
). I realize that would be a breaking change, but it would provide for the most natural way to use this.
And I believe that once such a package exists, you could create a final package that ties them all together quite nicely
Yes please, that! I use cross-env
and cross-var
and the amount of noise in my npm scripts is already ridiculous. For example:
"start": "cross-var cross-env NODE_PATH=$NODE_PATH$:server$:client$:. cross-env CALYPSO_ENV=development cross-env NODE_ENV=development npm run start:env",
Ideally I would want to write this:
"start": "env NODE_PATH=$NODE_PATH:server:client:. CALYPSO_ENV=development NODE_ENV=development npm run start:env",
No cross-env
before each variable, no separate commands for env
and var
adapters, shorter command name. I'm all in for trying to make something like that happen.
PS: Congrats @kentcdodds on your 1000 stars on cross-env
!
from cross-var.
@kentcdodds I would be cool to deprecate cross-var
if cross-env
could support complex statements. I'll create an issue on cross-env
tonight and we can start the conversation.
from cross-var.
@kentcdodds , Ok, based on the description of cross-env
, I wasn't sure if it was supposed to work with environment variables defined outside of a cross-env command
. Let me create an issue for cross-env
and see what others think about it.
Thanks.
from cross-var.
closing this issue since it's going to be addressed in cross-env
. looks like this repo will be deprecated soon once the issues are resolved. thanks everyone!
from cross-var.
I think using $:
in place of ;
(Windows) and :
(*nix) would work nicely. I've implemented it and cannot see any drawbacks, because environment variable names are primarily alphanumeric.
ie.
cross-var NODE_PATH=$NODE_PATH$:folder ..
from cross-var.
So, I love the idea of this, but I'm not sold on the $:
delimiter just yet.
cross-var NODE_PATH=$NODE_PATH$:folder ..
At first glance it makes me think (although I know it's not true) that NODE_PATH
needs dollar signs before and after to resolve $NODE_PASH$
which isn't the case, but for some reason it is throwing me off.
I'd like to briefly consider another delimiter. Any other suggestions? How about @DanReyLop or @kentcdodds
from cross-var.
Honestly, it seems to me like that would belong to a separate package as well.. I realize that this can get a little rediculous:
separate-package cross-var cross-env NODE_PATH=... etc.
But I really believe in the linux philosophy of doing one thing well. And I believe that once such a package exists, you could create a final package that ties them all together quite nicely:
cross-platform NODE_PATH=... etc.
from cross-var.
@DanReyLop, have you considered using nps? You could make a function that could handle this for you and really clean up your scripts (and perhaps such a function could be included in nps-utils :)
from cross-var.
I just realized that cross-env
should be able to do what cross-var
does. See kentcdodds/cross-env#32
from cross-var.
I just realized that cross-env should be able to do what cross-var does. See kentcdodds/cross-env#32
Nice, I didn't know that! Should we consider cross-var
deprecated then? No offense to @elijahmanor, but I think we all can agree that having cross-var
just provide a subset of the cross-env
functionality doesn't have any advantage, it's just confusing.
Looking at the code (haven't tried it yet), cross-env
has this exact same issue (doesn't adapt PATH
-style separators), so this discussion is still relevant, just in other repo :)
have you considered using nps? You could make a function that could handle this for you and really clean up your scripts (and perhaps such a function could be included in nps-utils :)
Didn't know about nps
either :). It looks really cool, just the ability to add comments and descriptions makes it very compelling to use. However, that file is not what other JS developers are used to (they expect everything on package.json
), and having to run every script like npm start realScriptName
is a bit weird. I'll keep that in mind if package.json
gets too complex, altough at that point maybe it would be better for us to go all-in with grunt
or gulp
.
from cross-var.
However, that file is not what other JS developers are used to (they expect everything on package.json)
True, but people get used to it
having to run every script like npm start realScriptName is a bit weird.
If you install nps
globally then it's just nps
and you can use prefixes so it's even less typing than npm ;-) (and even if you don't install nps
globally, npm start t.w
is still shorter than npm run test:watch
)
maybe it would be better for us to go all-in with grunt or gulp.
I think that grunt
and gulp
make things more complex than they need to be. I'd much rather use CLIs to accomplish my tasks and if something's more complex than can be represented in a single script I break out to an actual node script. I've not felt like grunt or gulp could have simplified my scripts since I stopped using them over two years ago. :)
But to each their own!
As to supporting this specific issue in cross-env
, we can file an issue there and talk about it. But I'm not going to go with $:
for the same reason @elijahmanor mentioned. We'll need to come up with something else...
from cross-var.
But to each their own!
Exactly. I'm not saying nps
is bad or anything like that, just that it's even more different than using plain npm
scripts. For context, right now our build system uses a Makefile
, and I'm experimenting to get rid of that (I use Windows so that's a pain). I feel that the more I deviate from "the norm", it will be more unlikely that'll be accepted :)
That's why this is not urgent for me, for now it's just a little experiment branch.
As to supporting this specific issue in cross-env, we can file an issue there and talk about it. But I'm not going to go with $: for the same reason @elijahmanor mentioned. We'll need to come up with something else...
I'll create an issue later today, we'll surely figure something out, this feature is very useful.
from cross-var.
Well, I didn't realize cross-env
did what cross-var
already did! @kentcdodds
The one thing cross-var
still does that I don't think cross-env
does yet is to allow for complex commands that include pipes and redirects (like the following)
"build:css": "cross-var \"node-sass src/index.scss | postcss -c .postcssrc.json | cssmin > public/$npm_package_version/index.min.css\""
Which is why I created the alternate syntax of having the first argument being a string that will be executed once all the replacements have been made. I wonder if that could be a feature of cross-env
as I know it is currently a Known Limitation
from cross-var.
Well, I didn't realize cross-env did what cross-var already did!
Me either!
You're right, cross-env
doesn't support that! Maybe it should! And that would resolve the known limitation issue as well, you're right!
from cross-var.
One benefit I find with cross-var
over cross-env
is that cross-var
works with environment variables defined "externally", such as environment variables defined by npm (e.g. npm_package_name
). I can use it to customize my scripts commands (e.g. use application name).
For instance, with:
"name": "my-nice-app",
scripts: {
"cross_env": "cross-env echo $npm_package_name",
"cross_var": "cross-var echo $npm_package_name"
}
This results in the following on Windows (with Windows cmd, CygWin bash or VSCode bash):
$ npm run cross_env
%npm_package_name%
$ npm run cross_var
my-nice-app
where I would expect to see my-nice-app
from cross-var.
That sounds more like a cross-env
bug than a benefit over cross-env
:) If you could please file that on cross-env
(a pull request would be awesome too, even if it just added a failing test), then we can get that resolved :)
from cross-var.
To close the loop, as discussed at kentcdodds/cross-env#91, using environment variables defined "outside of" this command (e.g. for environment variables defined by npm such as pm_package_name
) works fine with cross-var
, but not with cross-env
, so this still gives some value to cross-var
from cross-var.
Related Issues (19)
- Exit code transmission (1.0.3)
- Throws stderr maxBuffer exceeded error for some commands
- Crashes with version 1.0.3
- Support `${}` syntax HOT 1
- Unable to use in a folder whose name contains "src" HOT 3
- Only works for the first variable HOT 1
- Error if used before source command HOT 4
- Ignore a variable HOT 2
- DoesnΒ΄t work with two or more variables
- reducing dependencies HOT 1
- Dependency upgrade
- Cannot find module './_arrayEach' on windows
- Continue maintaining this project
- cross-var doesn't work properly with Powershell
- Deprecated Babel pacakge used HOT 2
- Error if you have any environment var set with key name having special chars
- Usage as dependency in apps that also use babel HOT 8
- $NODE and $NODE_DEBUG_OPTION get commingled HOT 1
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-var.