The server code should not be included in a library starter

[SteveALee]

The development server was add in #22 as a convenience but it cause confusion as discussed on #38

About the index.html, HMR and all that frontend stuff

Honestly, I wasn't totally convinced about including this , since for writing a library I do it in a TDD way, so I run npm run test:watch and start coding, either for a frontend or backend library. But apparently for some users is useful, see #22. I believe it would be the case where you don't apply TDD.

Some people gets confused by this and they think this starter is for a frontend library, which is not. So I was thinking in take that out to another branch, let's say frontend-starter. What do you think about this guys?

Even though I now see you are only generating a bundle.js, I now feel even more strongly the server should not be there at all. This starter is for a library which could contain anything - not necessarily UI related code, even if that is a common scenario. Unless you rename the package of course :)

Even a UI related library is unlikely to be a complete app so will need some context to run in. That is missing here as the HTML includes the library script directly.

Following that line of thought, the HTML page and server could be though of as a UI test framework and so should be moved under the test files. In actual fact I tried that, adding some more TS code for setting up my UI library code tests but ran into module resolution issues and then lost the will to code any more :)

As it is, the provided HTML and server are really only good for manual testing or smoke tests and it will be the template users choice on tools to automate integration testing etc - eg selenium.

Further it's arguably best to provide only unit tests for a library, whether part of TDD or not. It's arguable that use of a UI library in a HTML context is actually integration so again should not be part of your template. If the library generates HTML components they should have unit tests tat examine the out put. Admittedly unless you following functional or reactive principles that might be hard to so with out substantial mocking etc. But that's not the starter concern.

The presence of the UI code and server is confusing as you point out and hides the fact that creating a Typescript library that is useable in a wide range of contexts is actually fairly simple (see below). Quite a lot of code was added looking at the diffs

Those diffs show that the dev script was added to run the server and perhaps would have been better name 'serve'. As it is, it confused me as build:dev does something different - builds the package to distribute. Actually shouldnt both always be built? along with maps and .d.ts?

So I really think this server code should NOT be part of the core library template. It certainly should not be published, and thus is test / release logic only. It's actually easy to set up a simple web app server outside the library and link to the library dist directory so webpack sees it (using ln, mklink or npm linking). Once the lib is stable you just npm install as usual.

A separate fontend starter would be OK. but having it include a library is optional, perhaps just a monolith and let users add external libs if they like :)

---

Footnote - I'm interested to know how do you use this library for front end library TDD?

[SteveALee]

I'm now wondering I was wrong about the bundle NOT being importable by typescript and infact typescript can import the single js file with the separate types if --module UMD? I need to try it out!

Mind you the UBM does add boilerplate compared to separate files

[alexjoverm]

Hi @SteveALee,

I'm closing this since it has too much info, let's keep the relevant bits.

Follow up in #46

[alexjoverm]

As a general habit I'd say let's try to be concise when opening issues. I'll probably make a Github template for issues soon.

[SteveALee]

yeah, I was trying to cover all the reasons

tl;dr; it's to confusing! :)