This lays out a common project structure, and is hello-world buildable out of the box. It focuses on providing an easy-to-understand starting point for integrating with typescript and the rollup packager.
Rather than trying to set up to handle every possible variation, the intent of this template is to be opinionated about how a project should be organized—and then do that well.
I think the narrow focus serves the user better. Even if you chose a different path, it makes it easier to understand and to know how you wish to deviate.
- Simple starting point.
- Full typescript integration
- Generated Javascript files and source are placed in lib/ for easy cleanup and less clutter.
- Javascript configuration files redirect to typescript ones in ./config .
- Typescript build tools are fully supported in-project.
- Great experience out-of-the-box.
- Extensive descriptions of project structure
- Descriptions of plugins and options.
- A buildable, testable environment out-of-the-box
- Clear path to adding additional features
- Updates and optional features can be flexibliy merged in via git merges.
- Regular update scripts break when you make customizations.
- Git merges, at worst, give merge conflicts.
- Merge conflicts lay out what change was being attempted and why there was a conflict.
- Because you have the context for why your change conflicts, it's easier to resolve.
- The usual fallback for script-based template configuration is to manually figure out and make the changes.
- Continuous Integration Integration
The important files are the outputs included in the published module, and the sources that produce them. The rest are supporting mechanisms.
This describes the package, it's role in the world,
You should edit package.json, with special attention to these fields:
name:version:description:repository.url:keywords:license:bugs.url:homepage:
Three free Continuous Integration workflows are configured out of the box. Remove any you you do not need, or disable them in the relevant service.
You probably do not need multiple builds on multiple services, but this will let you see each and make a choice. For simple things at least, the features are very similar. It is very useful to be able to build and test on multiple environments in parallel, something each of the services provides.
This holds the built Javascript files. By default, three versions are built, for compatibility with various module systems. Ultimately, the world is moving toward the ECMAScript module format, but in the meantime,
This holds files in the ECMAScript module format.
This uses the CommonJS used traditionally by node.
This holds files in the UMD format, a flat file loadable by web browsers.
Data files to be used in documentation or runtime in the application.
This holds files used to globally configure the project. These are often redirected from the project root, to place them in one place, and to enable the use of typescript rather than javascript.
This holds code used to to build the main project. It is built before the main project is configured.
It is initially empty.
A generated directory with documentation. Some content may be installed from /assets
The generated API documentation via typedoc
This directory is created and managed by npm, via the npm install command.
This hierarchy contains the project's source code and related tests.
- .editorconfig
- .gitignore
- .npmignore — hides build infrastructure, sources, etc. from the final npm package.
- travis.yml -- configuration for building automatically on Travis
- .circle-ci/ -- configuration for building automatically on Circle CI
- .github/workflows -- configuration for building automatically on GitHub Workflows
- rollup.config.js -- redirects to /config/rollup.config.ts