A few observations

[SteveALee]

I'm finding this starter really useful! Thanks!

I've found a few things in using it and digging into the webpack docs

Is should raise as separate issues but for now...

• It's seems strange having an index.html for a library without any extra code using the library for UI.
• I'm adding "externals" to the webpack config to shrink the bundle by removing dependencies.
• To address both of these I'm using a second (derived) webpack config to build a UI bundle used in index.html for dev server use only.
• the build:dev script actually includes the HMR stuff which seems wrong if is there for dev use of the library. I'm not sure how you' detect this config as it's not -p
• docs say webpack -p infers -production - perhaps not cross platform though?
• The html Template viewport meta is a bad example - stopping scaling on mobile is a bad thing, especially from accessibility POV. But it's only for dev :)
• Should add a "module" to package.json to compliment the main for ES6 module consumers like Webpack so they can consume and treeshake etc. However I'm not sure how to create the require format from typescript - needs to be ES6 + includes.

See webpack 2 library building docs for more info

I hope these are useful

[RichiCoder1]

Had most of this feedback myself :). I ended up taking out all the HTML & HMR stuff where it wasn't relevant.

Should add a "module" to package.json to compliment the main for ES6 module consumers like Webpack so they can consume and treeshake etc. However I'm not sure how to create the require format from typescript - needs to be ES6 + includes.

If you properly declare your dependencies (or peer dependencies), you actually can just run tsc --outDir dist/src, and it'll produce Node 6+ compatible files w/ ES6 imports, as the default tsconfig is already configured correctly.
In theory, adding these lines to your package.json should wire everything up correctly. I admit, I still need to verify:

{
  "module": "dist/src/<library>.js",
  "scripts": {
    "postbuild": "tsc --outDir dist/src"
   }
}

Note: If you're using webpack to, well, pack any dependencies and not take a dependency on them, this won't work.

[SteveALee]

Yeah, I ended up doing that but still haven got a simple 'import {foo} from 'mylib' to work when using wepack against my umd bundle without crazy errors errors about no default export.

This stuff is crazy fragile and complex. I can't believe how long I've spent trying to get a basic lib build and consumer set up to NOT work. I have a hard deadline coming up fast . :(

You suggestion highlights one issue that confuses me. My expectation is webpack uses the entry to figure out which files to get tsc to compile via the load. But I found unless my tsconfig has a file entry all my files get processed, huh?

But I'll give it a go. :)

[RichiCoder1]

@SteveALee If you want to be explicit (which would probably be a good idea), I'd recommend adding this:

    "include": [
        "src/**/*"
    ],

to out your tsconfig.

[SteveALee]

now to generate a single .d.ts file for the library...

[alexjoverm]

Hi gentlemen! Thanks for raising the issue. Let's go by parts:

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?

I'm adding "externals" to the webpack config to shrink the bundle by removing dependencies.

Already had a question about this #33. I thought you must specify which libraries to exclude, so in the end the user has to know about that and include it by themselves on the externals and the peerDependencies in the package.json.

About the module key in package.json, or better said, optimizing bundles

This is on track, see #35 and #34. Also want to experiment with Rollup, and probably use it along with Webpack as Todd Motto does in ngxErrors library

I will not have too much time to work on this in the coming weeks, but feel free to send a PR and I'll review it ;)

docs say webpack -p infers -production - perhaps not cross platform though?

Don't know what you mean, but -p is equivalent to webpack --optimize-minimize --define process.env.NODE_ENV="'production'" as explained in Building for production on webpack docs

now to generate a single .d.ts file for the library...

You cannot auto-generate a single d.ts file, and there is no need for it, TypeScript resolves the different d.ts files. You just have to point to the entry d.ts file, which in this starter is already configured for you.

This is on track by the TypeScript team, and possible with external packages (dts-generator?), althought I haven't tried.

Yeah, I ended up doing that but still haven got a simple 'import {foo} from 'mylib' to work when using wepack against my umd bundle without crazy errors errors about no default export.

That should work out of the box with this library starter. I even use it myself for ShortcutJS.

It seems you're confusing here how modules work in ES6/TS. With that syntax you're not using a default export.

Also, keep in mind TypeScript treats differently the export default modules. Where in ES6 you'd import it as:

import whatever from 'whatever'`

In TypeScript would be:

import * as whatever from 'whatever'`

// Or

import whatever = require('whatever')

Check this issue for more info

---

Note: we're mixing here generic Webpack + TypeScript questions. Please let's try to here to report issues or questions related to this starter, and use StackOverflow or any other question.

[SteveALee]

Note: we're mixing here generic Webpack + TypeScript questions. Please let's try to here to report issues or questions related to this starter, and use StackOverflow or any other question.

Apologies - after a weekend of going round in circles it's hard to tell which is which. Especially as I tried to understand and fix tools usage issues in the template for my use.

I also got confused about what this starter is for. The server bit confused me. I now see you are only creating the global script for consumption in a browser. I expected something a bit different - along the lines of a typescript npm package library (collection of JS and .d.ts( usable form TS or JS node packages. Actually you currently need both, ie [3 separate versions of a library(http://marcobotto.com/compiling-and-bundling-typescript-libraries-with-webpack/)

I'll split up my comments and create new issues. I'm also very busy but hope to help out.

new issues: #40 #41

About the module key in package.json, or better said, optimizing bundles
This is on track, see #35 and #34. Also want to experiment with Rollup, and probably use it along with Webpack as Todd Motto does in ngxErrors library

But that only applies if you are distributing separate files- not a global script bundle

Don't know what you mean, but -p is equivalent to webpack --optimize-minimize --define process.env.NODE_ENV="'production'" as explained in Building for production on webpack docs

I only meant your script also defines NODE_ENV="'production'" which would appear to be redundant given what -p is equivalent too

now to generate a single .d.ts file for the library...

I subsequently thought that this makes no sense as TS will never use the generated single global bundle - not even relevant for intellisense. But now I wonder if I was wrong all along on #40 and infact typescript can import the single js file with the separate types if --module UMD? I need to try it out! But anyway I agree it's not need and if lib is separate js (not bundle) files then user can also import subfiles to keep size down (though not needed with treeshaking).

Yeah, I ended up doing that but still haven got a simple 'import {foo} from 'mylib' to work when using wepack against my umd bundle without crazy errors errors about no default export.

That should work out of the box with this library starter. I even use it myself for ShortcutJS.

It seems you're confusing here how modules work in ES6/TS. With that syntax you're not using a default export.

I agree, that type of import is valid and does not involve any default export. The problem that caused the error was that I was trying to import the generate UMD bundle from some test typescript. It obviously got confused - perhaps I need to specify module = UMD?

[RichiCoder1]

@alexjoverm

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?

I think that'd be smarter. Once I dug into the skeleton it made sense, but that did throw me for a loop at first glance.

Already had a question about this #33. I thought you must specify which libraries to exclude, so in the end the user has to know about that and include it by themselves on the externals and the peerDependencies in the package.json.

Yup! This all has to be done manually. One of the ironies of using webpack for this, as there's very little bundling happening :).

@SteveALee

I agree, that type of import is valid and does not involve any default export. The problem that caused the error was that I was trying to import the generate UMD bundle from some test typescript. It obviously got confused - perhaps I need to specify module = UMD?

You should indeed have to specify UMD if you want UMD, and also make sure you're setting the correct root for externals and loading those into the global context wherever you're loading them.

Great work btw @alexjoverm. This starter did seriously help reduce friction spinning up internal projects :)