Buslowicz / twc

TypeScript based, boilerplate-less, Polymer toolbox friendly Polymer Modules
32 stars 1 forks source link

Working with internal modules #39

Closed tpluscode closed 7 years ago

tpluscode commented 7 years ago

In my polymerTS code I export a shared behavior and then import it for elements that need it:

MyBehavior.ts

export MyBehavior { }

MyElement.ts

import MyBehavior from 'MyBehavior';

@behavior(MyBehavior)
export MyElement extends polymer.Base {
}

Now, when I twc MyElement.ts I get something like

Polymer(
  behaviors: [ MyBehavior1.MyBehavior ]
);

but 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.

Buslowicz commented 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).

tpluscode commented 7 years ago

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?

Buslowicz commented 7 years ago

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.

tpluscode commented 7 years ago

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

Buslowicz commented 7 years ago

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.

tpluscode commented 7 years ago

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?

Buslowicz commented 7 years ago

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.