Closed tpluscode closed 7 years ago
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. For now the only imports allowed are described here. In case described above, you can create a behavior module that exports behavior object to global namespace (happens by default), import just the file with behavior and use a global object. It may bring types issues for now (hopefully not), but I am working on types at this moment (#20).
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 --module
config, but that could be difficult. For now all I can think of is forcing one of the managers, whichever would be easiest to implement.
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.