How to develop standalone module for import into console

[jimmidyson]

DataMapper development will be done outside of this main repo & we will just be importing the module(s) as a separate dependency. Right now we don't have any external modules that show how to do this.

Considering this will be a common thing for consoles like this, @gashcrumb could you please look at putting together a template/starter/boilerplate for a module that we can reuse in future? We already have the https://github.com/redhat-ipaas/datamapper-ui repository set up, & we need to have something in there ready for the DataMapper team to start hacking on by the beginning of next week if possible?

[gashcrumb]

I sure can! Am already thinking we may want to have one anyways for generic components like lists, forms etc when we can't find or don't want to use any third party impls.

[jimmidyson]

Perfect! Also @jstrachan wants something similar for a FaaS UI too so this is going to be really useful. @kahboom This is what I mentioned to you on IRC about using separate npm packages for common stuff.

[gashcrumb]

Yeah, this is exactly the context I'm looking at this under, basically packing up a bunch of components/views/services as a typescript library that can then be imported into a console project, but also allow for development of the individual component easily enough.

And go figure, just running ng init doesn't do it all for us, poo :-)

On Wed, Jan 11, 2017 at 10:15 AM, Jimmi Dyson notifications@github.com wrote:

Perfect! Also @jstrachan https://github.com/jstrachan wants something similar for a FaaS UI too so this is going to be really useful. @kahboom https://github.com/kahboom This is what I mentioned to you on IRC about using separate npm packages for common stuff.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/redhat-ipaas/ipaas-client/issues/108#issuecomment-271894474, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVdrIff_9AgtyEaiFiteiEGJ5tuZhDvks5rRPH2gaJpZM4LgeQY .

[gashcrumb]

Just noting this here -> https://github.com/angular/material2/pull/948

[kahboom]

@gashcrumb - That's precisely the issue with creating them as npm packages, at least initially while they are still being worked on continuously; development would be a bit of a pain because we'd have to push up a new version whenever there is a change, and I'm assuming our dep versions would be locked in iPaaS UI. I can do some research to see what the best approach for this is, or did you have something in mind already / an example?

[gashcrumb]

@kahboom working on that right now :-)

[jimmidyson]

You can do something like yarn add file:./../your-project btw (note you can use relative paths, but that this isn't compatible with npm).

[jimmidyson]

Or indeed yarn link which might be more useful: https://yarnpkg.com/en/docs/cli/link

[gashcrumb]

Yeah, ideally we want that to work without having to do manual soft-links or some other muckery like we had to do with hawtio. I mean it worked, but being able to do npm link or obviously yarn link and have upstream modules that still work is totally nicer.

[gashcrumb]

So close but not quite working yet.

Leaving a link here so I don't forget -> https://medium.com/@cyrilletuzi/how-to-build-and-publish-an-angular-module-7ad19c0b4464#.44nqmnttb

[gashcrumb]

Working on figuring out this informative error -> http://stackoverflow.com/questions/41673916/error-in-is-not-an-ngmodule

[jimmidyson]

Have you seen https://github.com/jvandemo/generator-angular2-library btw? I haven't looked in any detail, just seen it used in a few different modules.

[gashcrumb]

Ooh, will look tomorrow... Sorta got past that issue and hit another one :-)

On Jan 16, 2017 6:18 PM, "Jimmi Dyson" notifications@github.com wrote:

Have you seen https://github.com/jvandemo/generator-angular2-library btw? I haven't looked in any detail, just seen it used in a few different modules.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/redhat-ipaas/ipaas-client/issues/108#issuecomment-272983590, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVdrDLLTqNnYx7WjI22y3DRGMH_2eKsks5rS_qkgaJpZM4LgeQY .

[kahboom]

@jimmidyson @gashcrumb - You may run into issues, since as of October 2016 (and to date, as far as I'm aware) lazy loading components from external ngModules (e.g. from npm) is not supported in angular-cli. See here for reference. The workaround is to load it via Webpack directly, like this. The actual code that makes this possible can be seen here.

[gashcrumb]

@kahboom yeah, hoping in the worst case we'd create a module that imports the npm packaged module and reference that from loadChildren so we can continue using angular-cli.

[gashcrumb]

@jimmidyson it works great! Doesn't deal with templates/styles though, also won't work with angular-cli which is a slight bummer. But lemme see what I can do with it anyways...

[kahboom]

For this specific use case I don't like the dependencies on either yeoman (Jimmi's solution) or Webpack (my solution), imo. I think we may have to use web components, but whatever gets the job done works.

[gashcrumb]

At least for the datamapper-ui repo we'd just maybe generate the code and be done with it. Though yeah, ideally I'd like something that works with angular-cli, it's a pain to remember how to kick off all the various types, and it's nice not to have to build out all the frameworky stuff.

Just want to link this issue here too -> https://github.com/angular/angular-cli/issues/1692

[gashcrumb]

Just gave this guy's workaround example a go from that last linked issue, I like this approach (for one, it just worked :-) ). Gonna give replicating the approach a try and make sure you can still use ng serve to develop the library separately.

[kahboom]

@jimmidyson @gashcrumb - Just to make sure we are not duplicating work here; you are working on making the ipaas-client importable as an npm or yarn package, correct? Not for reusable internal components or services. Just wondering since I was going to work on these issues this week, but can close them if you view them as separate tasks: #116 & #117

[gashcrumb]

@kahboom, yeah, I think those tasks are different and internal to ipaas-client. In my case I'm working on an easy approach to bring shared components into ipaas-client, like the datamapper when it gets going.

On that note, I think I have a workable solution based on that example repo I linked to, even works with yarn link, just have to document it more. But in any case, it's all going in here -> https://github.com/redhat-ipaas/datamapper-ui

So basically you can do yarn add git@github.com:redhat-ipaas/datamapper-ui.git in ipaas-client, then in our app.module.ts you can do:

import { ExampleModule } from 'datamapper-ui'

and then add ExampleModule as an imported module, then you can add the one component that's in there somewhere in the one of the app's templates:

<dev-example></dev-example>

Then run ng serve (or have it running I guess), the referenced component gets built along with the regular app bundle. We probably will have some work to do for supporting AOT and possibly lazy loading, but am liking this approach, especially when combined with yarn link as once you've imported the code, ng serve in the main app picks up your code changes in the component as well.

[ddramone]

@gashcrumb It's great what you done. I managed to to almost the same thing with standalone "sandbox" (aka dev-app in your lib) But what i mentioned, you're having your tsconfig file into dev-app. I suggest to move it out of that folder in the root. It will help IDE to consider tsconfig.json for lib folder also.

Also i suggest to have spec.ts files into your lib near your components.

https://angular.io/docs/ts/latest/testing/#!#q-spec-file-location

Why put specs next to the things they test? We recommend putting unit test spec files in the same folder as the application source code files that they test because

Such tests are easy to find You see at a glance if a part of our application lacks tests. Nearby tests can reveal how a part works in context. When you move the source (inevitable), you remember to move the test. When you rename the source file (inevitable), you remember to rename the test file. https://angular.io/docs/ts/latest/testing/#!#q-spec-file-location

Everything else looks good and i use it also with lot of success. Didn't tested with npm link yet, but i'm using npm pack comfortably.

[gashcrumb]

@ddramone Thanks for checking it out! I take no credit for coming up with it, kudos to @nsmolenskii for coming up with an example to work from.

Will try and move the tsconfig.json file, that's just where angular-cli put it. Also for the spec file I tried mucking with the test config to look for it under lib but the presence of the index.ts file under lib seemed to confuse things. But maybe I can come up with another approach that lets it sit in the same directory as the component, that would be nicer.

One note when using npm link or yarn link, it's possible you may need to temporarily get rid of node_modules in the component, otherwise there's build errors when you do the build from the consuming project. Probably just need to figure out a way to exclude that from the consuming project's tsconfig.json