fist of all ,thanks for your effort to the great tool
and then there is an question frustrating me for a long time;
here it is :
global variable for this cli-tool;
for example:
if we want to use $ variable as in global way, the suggestion way of our cli
is editing the "script:[]" in the file ".angular-cli.json";
in this senario:
we can get a script.bundel.js when server running;
but the the '$' is limtted in the script.bundel.js,not be shared,it's a 'fake global';
that's say if we use other libary based on jquery '$' not included in the 'script:[]',the '$'
can't be accessed!we have to do some work like ' import * as $ from jquery'
but in this way,we will get an error like '$ is not defined';
so,we have to leave the 'script:[]' empty.and then verything is go well,but the $ is not global;
that's to say:either we include all the libary in the 'script:[...]' or left it empty;
they can never coexist;
to say the least,even ,we can included all the libary files in the 'script:[]'
the script.bundel.js file may very large size ,that's not good idea;
IMHO,I know we create this cli too not for expert,just for out of the box using;
so maybe we don't encurage to do more complex job on config webpack. i really
agree with this!
In sum,we just want to find a way to set 'real global' variable like config setting
in webpack.config.js:
plugins:[new webpack.ProvidePlugin({
jQuery: 'jquery',
$: 'jquery',
jquery: 'jquery'
}) ];
so,how we go through this question?
thank you again.
You can run ng eject which ejects the webpack configuration, allowing you to modify it and add a ProvidePlugin.
yes,yes,yes
think that i'm a idiot to webpack config. all i can is "Fill in the blanks" of the config file as the official instruction ;so how about if we don't want use this feature. :)
@afontaine ng eject isn't mentioned anywhere in documentation. I occasionally found it after reading your comment. Maybe it should be mentioned in some .md file inside docs/?
@metamaker thanks for the suggestion. I just made this... https://github.com/angular/angular-cli/pull/5155
thanks all.
@delasteve @afontaine in fact i knew this "ng eject";
as i'v said, we should not 'encourage' doing too much work on webpack configing. we should keep this cli-tool simple to use for primary user who may have not rich experience on webpack;
so how about we make variable global if we don't want use this (‘ng eject’)feature?
if we use 'ng reject'
plugins:[new webpack.ProvidePlugin({
jQuery: 'jquery',
$: 'jquery',
jquery: 'jquery'
}) ];
and
script:['path/to/jquery.js'] in .angular-cli.json 'can never coexist.
What about "scripts" setting in .angular-cli.json?
This will, probably, should be used with types and/or typeRoots setting in typescript config files.
Regarding webpack.ProvidePlugin, there are no plans to add it in the CLI. It requires outside information that cannot be easily inferred, and doesn't provide as strong interop as global script support.
Supporting global script interop with typescript is rather easy and intuitive (imho), especially for people that aren't webpack wizards. And if you are a webpack wizard and 100% must have ProvidePlugin, then eject is just perfect for you.
I'm going to cross post my answer (https://github.com/angular/angular-cli/pull/3814#issuecomment-283630346) to your other comment here for visibility:
Ah so semantic is a jquery plugin? You never told me that 😃
Then it really depends on how that plugin functions unfortunately.
The global and local jquery instances are completely separate as that is the only way to ensure functionality.
When you add jquery to scripts it's exactly the same as adding it as a script tag in index.html. jquery is then on the global scope.
But when you import it via an import statement, you get a second local copy, that is not the same as the one on the global scope. This is intended by design, since ES6 modules are isolated.
The local copy does not have that semantic plugin. It's up to the plugin to provide import semantics compatibility. If that plugin only works by detecting jquery on the global scope then it cannot be used as a ES6 module.
For interop with packages that aren't meant to be used as ES6 modules your best bet is to work with the global scope. That means that you add jquery and all those plugins to the script array, and never import them in your TS code.
Then you create a src/typings.d.ts file and add declare var $: any there. If you have the real jquery type use that instead of any. That basically tells TypeScript to just assume there is a variable called $ in the global scope.
Then when you use it in your code you are using the global one and not a locally imported one. That global one has all the legacy jquery plugins you added.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Regarding
webpack.ProvidePlugin, there are no plans to add it in the CLI. It requires outside information that cannot be easily inferred, and doesn't provide as strong interop as global script support.Supporting global script interop with typescript is rather easy and intuitive (imho), especially for people that aren't webpack wizards. And if you are a webpack wizard and 100% must have
ProvidePlugin, then eject is just perfect for you.I'm going to cross post my answer (https://github.com/angular/angular-cli/pull/3814#issuecomment-283630346) to your other comment here for visibility:
Ah so
semanticis a jquery plugin? You never told me that 😃Then it really depends on how that plugin functions unfortunately.
The global and local
jqueryinstances are completely separate as that is the only way to ensure functionality.When you add
jqueryto scripts it's exactly the same as adding it as a script tag in index.html.jqueryis then on the global scope.But when you import it via an
importstatement, you get a second local copy, that is not the same as the one on the global scope. This is intended by design, since ES6 modules are isolated.The local copy does not have that semantic plugin. It's up to the plugin to provide
importsemantics compatibility. If that plugin only works by detectingjqueryon the global scope then it cannot be used as a ES6 module.For interop with packages that aren't meant to be used as ES6 modules your best bet is to work with the global scope. That means that you add jquery and all those plugins to the script array, and never import them in your TS code.
Then you create a
src/typings.d.tsfile and adddeclare var $: anythere. If you have the realjquerytype use that instead ofany. That basically tells TypeScript to just assume there is a variable called$in the global scope.Then when you use it in your code you are using the global one and not a locally imported one. That global one has all the legacy jquery plugins you added.