Skip to content
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

frustrated with the global variable like $!!! #5139

Closed
guzuomuse opened this issue Mar 1, 2017 · 9 comments
Closed

frustrated with the global variable like $!!! #5139

guzuomuse opened this issue Mar 1, 2017 · 9 comments

Comments

@guzuomuse
Copy link

guzuomuse commented Mar 1, 2017

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.

@afontaine
Copy link

You can run ng eject which ejects the webpack configuration, allowing you to modify it and add a ProvidePlugin.

@guzuomuse
Copy link
Author

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. :)

@dmytro-y-dev
Copy link

dmytro-y-dev commented Mar 1, 2017

@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/?

@delasteve
Copy link
Contributor

@metamaker thanks for the suggestion. I just made this... #5155

@guzuomuse
Copy link
Author

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?

@guzuomuse
Copy link
Author

guzuomuse commented Mar 2, 2017

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.

@ValeryVS
Copy link
Contributor

ValeryVS commented Mar 2, 2017

What about "scripts" setting in .angular-cli.json?
This will, probably, should be used with types and/or typeRoots setting in typescript config files.

@filipesilva
Copy link
Contributor

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 (#3814 (comment)) 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.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants