-
Notifications
You must be signed in to change notification settings - Fork 1
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
Working with internal modules #39
Comments
As TS modules here are translated to HTML modules, there is no module import and for now it's impossible to import specific members of a module. I am more than happy to implement some sort of this case handler, but it would not meet ES6 modules specs. |
I'm thinking that typescript already has it's way for compiling ES6 imports into other kinds of modules like AMD, commonjs, system etc. Maybe it would be enough to replicate (or reuse) what tsc does when it produces its output? |
But that would require to bring systems like System.JS, Browserify, Require.JS etc to build, which would be an additional dependency, while we already have html imports, which Polymer is based on. The idea of TWC is to compile to native Polymer modules, so unless somebody gives me a nice idea of how to solve it, I would be against implementing that. |
HTML Imports and ES modules are not alternatives. They will eventually work together to solve two different problems. Wanting to use imports to load javascript dependencies is not going against the platform or Polymer, IMO. I see how it is a compromise however Module imports are not yet supported in browsers and to require some kind of workaround. It's a PITA that Polymer is kind of forced to live without them and rely only on globals for JS dependencies |
True. Personally I just can't wait till ES Modules are finished and native to the browsers. Till that happens, we have to rely on polyfills and as we got one already. I could, however, add support for a loader, but that might take a longer moment. I will investigate that later, probably after I finish Beta 2. |
The problem I see with leveraging TypeScript's module targeting is that a particular choice would in worst case force a consumer to use multiple types of packages: AMD, commonjs or SystemJS. How would that work? |
I could try to handle all options of |
In my polymerTS code I export a shared behavior and then import it for elements that need it:
MyBehavior.ts
MyElement.ts
Now, when I
twc MyElement.ts
I get something likebut the
MyBehavior1.MyBehavior
is not emitted anywhere.MyBehavior.ts
is also not emitted.Is there a way to support this scenario currently? I think it's actually a bigger case here, where one would want to organize their code in smaller internal modules.
The text was updated successfully, but these errors were encountered: