Skip to content

Question: Migrating from namespace to external modules #15774

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

Closed
CodySchaaf opened this issue May 11, 2017 · 2 comments
Closed

Question: Migrating from namespace to external modules #15774

CodySchaaf opened this issue May 11, 2017 · 2 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@CodySchaaf
Copy link

This is just a question, and I know that is not encouraged, but I'm having trouble finding any help on stackoverflow. There are a few posts with no answers and the people asking are still stuck.

We have been using TypeScript at my company for a little over 3 years with our AngularJs app. Everything is written in TypeScript using internal modules (now over 2556 files...). It has become increasing clear that we should be using external modules. For example wanting to take advantage of build tools like webpack to utilize tree shaking ect. Not to mention our upgrade to angular2.

Is there any documentation on upgrading in a more piecewise fashion? It doesn't look like you can require external components inside the internal modules without types breaking, and importing from the namespace in an external modules is a little weird.

Also Most the tsc plugins for webpack and browserify can't validate certain sub directories separately, they hit the whole directory ever time.

Not sure if my only option is to figure out a way to convert all files at once.

Any thoughts or direction would be great.

Thanks!

@mhegazy
Copy link
Contributor

mhegazy commented May 11, 2017

There is relevant discussion in #12473.

I also have a comment related to this in #8004 (comment). what we have seen is it is always your logic, and not the file organization that is the most painful to migrate.

My recommendation is to do it incrementally. pick a leaf component, and move it to a module, make sure you keep it in the global scope as well to keep your existing code working, then find its users, migrate them, and so on recursively. hopefully the first couple of components you migrate will shed some light on the architectural changes you need to make.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label May 11, 2017
@mhegazy
Copy link
Contributor

mhegazy commented May 25, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed May 25, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

2 participants