Skip to content

Consider supporting metadata.typescriptOptions #96

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
guybedford opened this issue Feb 1, 2016 · 8 comments
Closed

Consider supporting metadata.typescriptOptions #96

guybedford opened this issue Feb 1, 2016 · 8 comments

Comments

@guybedford
Copy link
Contributor

In the Babel and Traceur plugins we support options via metadata for per-module compilation options, which can be a useful feature.

It means replacing the options check with options = extend(extend({}, System.typescriptOptions), load.metadata.typescriptOptions).

@frankwallis
Copy link
Owner

This sounds like a good idea but not a big priority ATM. It also opens up some questions - should it load tsconfig.json files from within packages etc. If anyone has use-case for this feature then please share.

@guybedford
Copy link
Contributor Author

It can be even for a restricted set of options say setting the module format. The idea is really just to allow per-module setting of typescriptOptions to avoid it being a "global" configuration.. it's basically just ensuring true encapsulation.

@aluanhaddad
Copy link
Contributor

This would be great!

@aluanhaddad
Copy link
Contributor

I would like to take a crack at implementing this when I get some time.

@frankwallis
Copy link
Owner

That would be awesome, I will be interested to see your approach. I have thought about it and given the current structure I think it will be awkward to support completely independent compilation of packages, without a big refactoring. It might be easier to leave the core options handing as it is and just allow packages to override a subset of the options when their files are transpiled/type-checked. I don't know if that is enough for your use-case though?

@aluanhaddad
Copy link
Contributor

My use cases mainly involve transpiling to multiple target module formats and toggling certain compilerOptions at package level.

In part this has to do with wanting to run certain packages from source instead of loading their bundles during the development workflow.

I definitely think it will be difficult but I think the right approach is, as you suggest, starting with supporting a small subset of the simpler configuration options. At the least this could be a nice proof of concept.

@frankwallis
Copy link
Owner

This should be considerably easier from 0.6.0 onwards as I have split out options from CompilerHost and it is now passed into transpile. It also seems to be necessary to support systemjs 0.20 so I will be progressing this now.

@frankwallis
Copy link
Owner

This has been implemented in 7.0.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants