alexjoverm/typescript-library-starter

Starter kit with zero-config for building a library in TypeScript, featuring RollupJS, Jest, Prettier, TSLint, Semantic Release, and more!

TypeScript library starter

A starter project that makes creating a TypeScript library extremely easy.

Usage

git clone https://github.com/alexjoverm/typescript-library-starter.git YOURFOLDERNAME
cd YOURFOLDERNAME

# Run npm install and write your library name when asked. That's all!
npm install

Start coding! package.json and entry files are already set up for you, so don't worry about linking to your main file, typings, etc. Just keep those files with the same name.

Features

• Zero-setup. After running npm install things will setup for you 😉
• RollupJS for multiple optimized bundles following the standard convention and Tree-shaking
• Tests, coverage and interactive watch mode using Jest
• Prettier and TSLint for code formatting and consistency
• Docs automatic generation and deployment to gh-pages, using TypeDoc
• Automatic types (*.d.ts) file generation
• Travis integration and Coveralls report
• (Optional) Automatic releases and changelog, using Semantic release, Commitizen, Conventional changelog and Husky (for the git hooks)

Importing library

You can import the generated bundle to use the whole library generated by this starter:

import myLib from 'mylib'

Additionally, you can import the transpiled modules from dist/lib in case you have a modular library:

import something from 'mylib/dist/lib/something'

NPM scripts

• npm t: Run test suite
• npm start: Run npm run build in watch mode
• npm run test:watch: Run test suite in interactive watch mode
• npm run test:prod: Run linting and generate coverage
• npm run build: Generate bundles and typings, create docs
• npm run lint: Lints code
• npm run commit: Commit using conventional commit style (husky will tell you to use it if you haven't 😉)

Excluding peerDependencies

On library development, one might want to set some peer dependencies, and thus remove those from the final bundle. You can see in Rollup docs how to do that.

Good news: the setup is here for you, you must only include the dependency name in external property within rollup.config.js. For example, if you want to exclude lodash, just write there external: ['lodash'].

Automatic releases

Prerequisites: you need to create/login accounts and add your project to:

• npm
• Travis CI
• Coveralls

Prerequisite for Windows: Semantic-release uses node-gyp so you will need to install Microsoft's windows-build-tools using this command:

npm install --global --production windows-build-tools

Setup steps

Follow the console instructions to install semantic release and run it (answer NO to "Do you want a .travis.yml file with semantic-release setup?").

Note: make sure you've setup repository.url in your package.json file

npm install -g semantic-release-cli
semantic-release-cli setup
# IMPORTANT!! Answer NO to "Do you want a `.travis.yml` file with semantic-release setup?" question. It is already prepared for you :P

From now on, you'll need to use npm run commit, which is a convenient way to create conventional commits.

Automatic releases are possible thanks to semantic release, which publishes your code automatically on github and npm, plus generates automatically a changelog. This setup is highly influenced by Kent C. Dodds course on egghead.io

Git Hooks

There is already set a precommit hook for formatting your code with Prettier 💅

By default, there are two disabled git hooks. They're set up when you run the npm run semantic-release-prepare script. They make sure:

• You follow a conventional commit message
• Your build is not going to fail in Travis (or your CI server), since it's runned locally before git push

This makes more sense in combination with automatic releases

FAQ

Array.prototype.from, Promise, Map... is undefined?

TypeScript or Babel only provides down-emits on syntactical features (class, let, async/await...), but not on functional features (Array.prototype.find, Set, Promise...), . For that, you need Polyfills, such as core-js or babel-polyfill (which extends core-js).

For a library, core-js plays very nicely, since you can import just the polyfills you need:

import "core-js/fn/array/find"
import "core-js/fn/string/includes"
import "core-js/fn/promise"
...

What is npm install doing on first run?

It runs the script tools/init which sets up everything for you. In short, it:

• Configures RollupJS for the build, which creates the bundles
• Configures package.json (typings file, main file, etc)
• Renames main src and test files

What if I don't want git-hooks, automatic releases or semantic-release?

Then you may want to:

• Remove commitmsg, postinstall scripts from package.json. That will not use those git hooks to make sure you make a conventional commit
• Remove npm run semantic-release from .travis.yml

What if I don't want to use coveralls or report my coverage?

Remove npm run report-coverage from .travis.yml

Resources

• Write a library using TypeScript library starter by @alexjoverm
• 📺 Create a TypeScript Library using typescript-library-starter by @alexjoverm
• Introducing TypeScript Library Starter Lite by @tonysneed

Projects using typescript-library-starter

Here are some projects that use typescript-library-starter:

• NOEL - A universal, human-centric, replayable event emitter
• droppable - A library to give file dropping super-powers to any HTML element.
• redis-messaging-manager - Pubsub messaging library, using redis and rxjs

Credits

Made with ❤️ by @alexjoverm and all these wonderful contributors (emoji key):

Ciro 💻 🔧	Marius Schulz 📖	Alexander Odell 📖	Ryan Ham 💻	Chi 💻 🔧 📖	Matt Mazzola 💻 🔧	Sergii Lischuk 💻
Steve Lee 🔧	Flavio Corpa 💻	Dom 🔧	Alex Coles 📖	David Khourshid 🔧	Aarón García Hervás 📖	Jonathan Hart 💻
Sanjiv Lobo 📖	Stefan Aleksovski 💻	dev.peerapong 💻	Aaron Groome 📖	Aaron Reisman 💻	kid-sk 📖	Andrea Gottardi 📖
Yogendra Sharma 📖	Rayan Salhab 💻

This project follows the all-contributors specification. Contributions of any kind are welcome!

typescript-library-starter's Issues

Maybe add a note on https://unpkg.com

This comes with no SLAs etc but is an easy way to get a library onto a CDN

https://unpkg.com

webpack.config.ts uses double quotes instead of single and fails lint

I had fresh clone of the repo and was attempting to add new feature and it push it and it failed due to error in webpack.config.ts

E:\Repos\ts-test-package [master ↑2 +0 ~2 -0 !]> npm run lint

> @mattmazzola/[email protected] lint E:\Repos\ts-test-package
> tslint -e **/node_modules/** -e **/dist/** **/*.ts


webpack.config.ts[3, 25]: " should be '

npm ERR! Windows_NT 10.0.14393

Change outDir or declarationDir when issue is fixed on ATL

Relates to #18

That was fixed temporally, but it would be nicer to generate types under a folder called types instead of `src.

This is dependant on a fix on ATL end.

Fixed git information on gh-pages-publish

Hi, I've started to use the typescript-library-starter and I saw that in this line https://github.com/alexjoverm/typescript-library-starter/blob/master/tools/gh-pages-publish.ts#L25 the git information is hard-coded. I'm pretty sure that this can be solved in a better way and I wanted to notify you guys about it.

I'll see if I'm able to send a PR fixing this :)

Use awesome-ts-loader instead of ts-loader

Change default tslint formatter to codeFrame

Proposing to change the default formatter for tslint to codeFrame since it offers more helpful information to the developer. It will include sample code and the rules which was violated.

Example default (prose):

test/index.test.ts[7, 3]: file should end with a newline

Example (codeFrame):

test/index.test.ts
file should end with a newline (eofline)
  5 |     expect(add(1, 2)).toBe(3)
  6 |   })
> 7 | })
    |  ^

Unhandled promise rejection

On running the test command I'm getting the following warnings:

(node:73480) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): TypeError: require(...) is not a function
(node:73480) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This is on a fresh clone of typescript-library-starter. Any idea of how to fix?

PS: this project template is really useful, thanks!

Integrate Greenkeeper.io

Warn about excluding external dependencies in docs

Discussed in #38, a common case for writing a library is to exclude external libraries (i.e.: react, lodash...). That's something that the user has do declare manually in the Webpack or Rollup configs.

But what we can do is add a heads up in the Readme to warn about this common case

Make git hooks disabled by default, with an option to easily enable them

Install of semantic-release fails on Windows 10

This isn't really issue for this repo but for semantic-release and I opened issue there:
https://github.com/semantic-release/semantic-release/issues/372

But I assume since this repo is targeted twoards TypeScript devs this is more likely to be people who use Microsoft / Windows and thought surely one of the maintainers has found a solution?

If there's no known work-around then maybe just add a warning to that section of the README explaining that you can't really use the semantic-release features of the starter kit if you're on Windows and close this issue.

Add "repository" in package.json for Semantic release

Semantic release needs the repository field in order to work. For that:

• Include an empty key in the package.json
• Rename tools/init-hooks.js to semantic-release-prepare.js and include a warning for the repository.url
• Update docs

An in-range update of ts-node is breaking the build 🚨

Version 3.0.5 of ts-node just got published.

Branch	Build failing 🚨
Dependency	ts-node
Current Version	3.0.4
Type	devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As ts-node is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details

• ❌ bitHound - Dependencies null Details
• ❌ bitHound - Code null Details
• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

Commits

The new version differs by 7 commits.

• c18331a 3.0.5
• 5cf97b1 Add --inspect-brk to known flags (#343)
• 7dfb3e3 Pin node tests at 6.x (#340)
• 633d537 chore(package): update chai to version 4.0.1 (#337)
• b751a56 Define exports and improve getTypeInfo help (#332)
• d018300 Update yn default option
• cc3bf22 Expose _ bin file for consumers to use

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Generate accurate sourcemaps

How to exclude depending lib

Hi!

Lets say I'm creating an RxJs operators lib. I add the lib as a dep inpackage.json but that includes rxjs inside the exported bundle.

What is the best way to exclude it from the bundle?

I've tried using the webpack ingnore plugin like this

const plugins = [
  new CheckerPlugin(),
  new TsConfigPathsPlugin(),
  new webpack.IgnorePlugin(/rxjs/),
  new HtmlWebpackPlugin({
    inject: true,
    title: libraryName,
    filename: 'index.html',
    template: join(__dirname, 'template/index.html'),
    hash: true,
    chunks: ['common', 'index']
  })
]

but that replaces the includes with a throw

/***/ }),
/* 42 */
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0__maybe__ = __webpack_require__(20);
throw new Error("Cannot find module \"rxjs/Observable\"");
throw new Error("Cannot find module \"rxjs/add/observable/of\"");

Any help appreciated!

Thanks and continue the good work ;)

PS: Have you discussed using rollup instead of webpack for creating the bundle?

https://medium.com/webpack/webpack-and-rollup-the-same-but-different-a41ad427058c

type definitions not generated if atl useCache

The current version only generates type definitions on first run if awesomeTypescriptLoaderOption useCache is true (as it is after npm install). The subsequent runs don't generate type definitions.

Also, on the first run the type definitions are generated into dist/src/, not in the dist/types/ which is the typings location specified in package.json.

Use stricter style by setting noImplicitAny to true

Introduce babel-preset-env

a branch to go with the egghead tutorial

There's a tutorial for this repo on egghead.io, however, there's not a branch that matches the project setup that the author starts off with in the videos.

Could we get this, please?

Enable webpack 2 tree shaking for dead code elimination

Files should be removed as part of init

The following files do not make sense after init has been run as the files are then user's personal project, nothing to do with this starter (though maybe leave a 'poweredby' file?)

• tools/init.js - is it even safe to run it twice?
• .all-contributorsrc
• LICENCE - though users should be encouraged to chose one, may link to git hubs chooser?
• yarn.lock

Gh-pages-publish repository parameter

Hi,
I got a problem when I tested some features of library-starter. Problem is in this line in file tools/gh-page-publish.js:

let repository = url.parse(pkg.repository)

But config file contains a little bit different node:

"repository": { "type": "git", "url": "https://someurlhere.git" }

So maybe we should parse pkg.repository.url? Or i miss something during installation process :(

Add Prettier

Would you consider adding Prettier to starter? I can prepare PR for this.
https://github.com/prettier/prettier-eslint

Setup different bundles

@hrajchert suggested in #33 to use RollupJS instead of Webpack. After reading the following articles, it seems (by the date of April 2017) RollupJS fits better for library usage:

• The cost of small modules
• Webpack and Rollup: the same but different

Axel Rauschmayer describes pretty well in the article "Setting up multiplatform npm packages" what we can use as a standard convention for providing different bundles in npm packages.

Jason Aden does it as well in a talk in the ngconf talk "Packaging Angular libraries"

Add .editorconfig file

A kind of expected example is all-contributors/cli#36, although some rules are flexible here

'Unexpected token` when running rollup with axios

Im getting the following error when running npm run start with the default rollup.config.js.

Error: Unexpected token
node_modules/axios/package.json (2:9)
1: {
2:   "_from": "axios@^0.16.2",

Unknown compiler option '-c'.

After running yarn install and yarn start, this is the error i get:

> tsc-watch --onSuccess 'rollup -c'
error TS5023: Unknown compiler option '-c''.

Use a single tsconfig file

Types are generated on dist/src instead of dist/types

Relates to #16

Unable to debug Jest tests using VSCode

With the default project, I am unable to set breakpoint in visual studio code.

Here's my launch.json:

{
  // http://markuseliasson.se/article/debugging-jest-code/
    "version": "0.2.0",
    "configurations": [
        {
          "name":"Jest Tests",
          "type":"node",
          "request":"launch",
          "program":"${workspaceRoot}/node_modules/jest-cli/bin/jest.js",
          "stopOnEntry":false,
          "args":[
              "--runInBand"
          ],
          "cwd":"${workspaceRoot}",
          "preLaunchTask":null,
          "runtimeArgs":[
              "--nolazy"
          ],
          "env":{
              "NODE_ENV":"development"
          },
          "console":"integratedTerminal",
          "sourceMaps":false
        }
    ]
}

Generated umd.js.map and es5.js.map files do not point to the .ts source files

This starter is great, except for one thing. The generated files in dist point to files in compiled/, which:

1. are not the Typescript source files in src
2. do not get distributed in the final bundle anyway

Sample from a fresh build:

{"version":3,"file":"hello.umd.js","sources":["../compiled/hello.js"],"sourcesContent":["// Import here Polyfills if needed. Recommended core-js (npm i -D core-js)\n// import \"core-js/fn/array.find\"\n// ...\nvar DummyClass = (function () {\n    function DummyClass() {\n    }\n    return DummyClass;\n}());\nexport default DummyClass;\n//# sourceMappingURL=hello.js.map"],"names":[],"mappings":";;;;;;AAAA;;;AAGA,IAAI,UAAU,IAAI,YAAY;IAC1B,SAAS,UAAU,GAAG;KACrB;IACD,OAAO,UAAU,CAAC;CACrB,EAAE,CAAC,CAAC,AACL,AAA0B,AAC1B;;;;"}

Unless I'm missing something, these source maps don't work for their intended purpose.

For now I ended up relying on rollup-plugin-typescript2, which seems to preserve maps to the original Typescript source files, but I don't know if I can trust it.

Cheers,

[Possible Bug] Jest picks up test outside the test folder

I experimented a bit with the dependencies and renamed my node_modules folder and then noticed that jest tried to run the tests in the renamed node_modules folder, because it does not match the coveragePathIgnorePatterns anymore.

I for myself found this behavior somewhat unexpected and inconsistent, because I would expect that if there is a test folder, only this folder would be recognized by jest. A solution would possibly be the usage of collectCoverageFrom and explicitly declaring the test folder.

If this is instead expected behavior, then everything is fine 😜

[bug] Declaration files not generated for files with only interfaces/no javascript.

Due to some long-standing issue with awesome-typescript-loader:

s-panferov/awesome-typescript-loader#411
s-panferov/awesome-typescript-loader#428
s-panferov/awesome-typescript-loader#432

Files with no javascript-producing code are omitted from the declaration file process. For example:

Case 1:

// src/color-interface.ts
export interface ColorInterface {
   r: number;
   g: number;
   b number;
}

// src/color.ts
import { ColorInterface } from './color-interface';

export class Color implements ColorInterface {
   r: number;
   g: number;
   b number;
}

Case 2:

// src/color-interface.ts
export interface ColorInterface {
   r: number;
   g: number;
   b number;
}

export var __WORKAROUND = 1;

// src/color.ts
import { ColorInterface } from './color-interface';

export class Color implements ColorInterface {
   r: number;
   g: number;
   b number;
}

In Case 1, types/color-interface.d.ts is not generated, but types/color.d.ts is generated. Furthermore, types/color.d.ts contains a non-resolvable reference to ./color-interface.

In Case 2, both types/color-interface.d.ts and types/color.d.ts are generated and everything works as expected.

This occurs silently-- webpack throws no errors when building the library, but errors appear when trying to use the library from a consuming project:

// main.ts
import { Color } from 'my-library';

let color = new Color();

ERROR in [at-loader*] ./node_modules/my-library/dist/types/color.d.ts:1:31
    TS2307: Cannot find module './color-interface'.

*note that the error above mentions at-loader, this is just because I happen to be using at-loader in my other project. The error is due to the fact that types/color-interface.d.ts does not exist.

Probable fix (not sure of other implications, haven't tested):

• switch from awesome-typescript-loader to ts-loader
• install babel-loader
• add babel-loader to /\.ts$/ rule before ts-loader (like so)

  module: {
          rules: [
              {
                  test: /\.ts$/,
                  use: [
                      {
                          loader: 'babel-loader'
                      },
                      {
                          loader: 'ts-loader',
                      }
                  ]
              }
          ]
      },

• change declarationDir in tsconfig.json to types (as tsloader appears to use the provided path relative to the webpack config's output.path)

Again, this needs testing. I'll do a pull request shortly.

Set strictNullChecks to true by default

Try out Rollup in replacement of Webpack

Separate frontend-only stuff in another branch

As discussed in #38, having HRM, dev-server and all that stuff confuses people thinking this starter is for frontend libraries, but it is universal since you can use it for both.

Let's separate that stuff in a different branch. Things to do:

• Move HRM and all that stuff made on #22 to the frontend branch
• Config the environment config of jest to node for the default (backend) branch
• Add some docs at the begining pointing out the existence of these 2 versions

jest config broken

I can't find a way to instantiate the generated DummyClass in test case without errors. Runnin npm test results in

   ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){require('ts-jest').install();import DummyClass from "../src/liblib";
                                                                                                                      ^^^^^^
SyntaxError: Unexpected token import

  at e (node_modules/jest-runtime/build/transform.js:320:12)

The server code should not be included in a library starter

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?

git not initialized when path has whitespaces

A few observations

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

ES5 and UMD Bundles

I think you may have answered this somewhere already, but what's the reason for generating both ES5 and UMD bundles?

Compiling multiple typescript files

This starter works great when your library has only one TypeScript file, but not to well it you have > 1 file. Would it be possible to configure the build process to build everything in a folder rather than a single? file

Source...

src
    \foo
        \bar.ts
        \baz.ts

...should produce...

\dist
    \compiled
        \foo
            \bar.js
            \baz.js

Concider adding "externals" to the webpack config to shrink the bundle by removing dependencies

(continued from #38)

As it stand the generated .js includes all dependencies.

It rather depends on usage but I think this is incorrect

If the consuming code includes several libraries that are built with this starter and have common dependencies a duplication is likely to occur in the global (root) namespace.

Better the dependencies at left for the user to figure out - though this strays into the pain of manual dependency management

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.

Externals only drops stuff from the generated bundle.js - so adding to package.json will make no difference. They need to be added in the code that includes the library script.

But yes this could be a right royal pain as noted above.

Another problem with externals is you seem to need to declare the module schemes and that would be a pain to manage.

npm install failing on bash on Ubuntu on Windows

It looks like the run of the post install script fails with the following. At least I never get prompted for the library name

> [email protected] postinstall /mnt/c/projects/spikes/typescript-library-starter/node_modules/spawn-sync
> node postinstall

npm WARN lifecycle [email protected]~postinstall: cannot run in wd %s %s (wd=%s) [email protected] node tools/init /mnt/c/projects/spikes/typescript-library-starter
[email protected] /mnt/c/projects/spikes/typescript-library-starter
```

some error when npm run build or npm start

Error: Unexpected token
node_modules/tough-cookie/package.json (2:9)
1: {
2:   "_args": [
            ^
3:     [
4:       {

Trouble building with 'Cannot call a namespace ('Knex')'

Hi there, apologies in advance if these are silly questions but I'm new to Rollup and I'm not quite sure to do this.

I'm writing a lib that uses Moment and Knex. In the source, I've imported them as import * as moment from "moment". Typescript compiles fine, but this causes Rollup to throw the following errors:

Cannot call a namespace ('Knex')
Cannot call a namespace ('moment')

If I change the imports to import moment from "moment", then Rollup manages to complete, but if I try to use the compiled code I get Module <project_path>/node_modules/moment/moment has no default export. I also tried setting "allowSyntheticDefaultImports": true on both the library itself and the consuming project, but then I get Cannot find module 'moment'.

I've also tried changing the imports to requires but that didn't do anything either 😕 .

Any help would be hugely appreciated.

rollup.config.js

import includePaths from 'rollup-plugin-includepaths';
import resolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
const pkg = require('./package.json');
const { camelCase } = require('lodash');

const libraryName = 'argo-serverless-common';

const externals = [
  'aws-sdk/clients/cognitoidentityserviceprovider',
  'aws-sdk/clients/dynamodb',
  'isomorphic-fetch',
  'knex',
  'lodash',
  'memcached',
  'moment',
  'pg',
  'validatorjs',
];

export default {
  entry: `compiled/${libraryName}.js`,
  targets: [
    { dest: pkg.main, moduleName: camelCase(libraryName), format: 'cjs' },
		// { dest: pkg.main, moduleName: camelCase(libraryName), format: 'umd' },
		{ dest: pkg.module, format: 'es' }
  ],
  format: 'iife',
  sourceMap: true,
  // Indicate here external modules you don't wanna include in your bundle (i.e.: 'lodash')
  external: externals,
  plugins: [
    // Allow relative path resolving
    includePaths({
      include: {},
      paths: ['compiled'],
      external: externals,
      extensions: ['.js', '.json', '.html']
    }),
    // Allow bundling cjs modules (unlike webpack, rollup doesn't understand cjs)
    commonjs({
      include: [
        'node_modules/knex/**',
        'node_modules/moment/**',
        // 'node_modules/moment/**',
      ]
    }),
     // Allow node_modules resolution, so you can use 'external' to control
     // which external modules to include in the bundle
     // https://github.com/rollup/rollup-plugin-node-resolve#usage
    resolve({
      modulesOnly: true,
    }),
  ]
}

Include this repo in a travis build

Some fixes on tools/init.js must be done in order to be non-blocking

Also add corresponding badges

Feature Request: Validate commit message

Would you consider using validate-commit-msg for validating commit messages? It is a good practice.

Remove default author

should be replaced by git credentials..

maybe install script by it self can retrieve git user from bash through this way:
git config user.email
git config user.name

Forgot to remove `.babelrc`?

Should have been done with b469c83, I guess. Nice setup though!