Dizmo generator
- Prerequisites
- How does dizmoGen work?
- Installation
- Quick start
- Caching
- Upgrading the Build System
- Skeleton
- Package manager: package.json
- NPM scripts
- CLI options
- Build
- Extended sub-generators
- Miscellanea
- Troubleshooting/FAQ
- Copyright
-
Node.js v14.15.5 LTS (or higher); for Linux distribution based packages (
deb
orrpm
) see also binary distributions.
DizmoGen is a generator to create a project folder that contains a skeleton for a new dizmo. Further, the build scripts needed to turn the source code into a packed and installable dizmo artifact (*.dzm
) are present as well. The generator itself is based on the Yeoman generator toolkit. After the initial generation of a project, neither dizmoGen nor Yeoman are required anymore to build your dizmo.
Use any text editor or IDE to edit the generated source code. Once ready you can use the build scripts to turn your project into a correctly formatted and packed dizmo: Invoking npm run <script>
uses internally a Node.js based tool named gulp, which orchestrates the entire build process to turn your source code into a dizmo. Possible <script>
commands are build
, lint
, clean
etc.
As the totality of all build scripts with their dependencies account for more than 100
MBytes, the dependencies are excluded when pushing a source folder to a remote Git repository. So, if you get a dizmo project from an external origin it is necessary to install them first. This is done within the build process automatically or can be triggered manually by invoking npm install
from within the project folder, which will create a folder named node_modules
, which should never be included in the Git repository!
The options and commands available to build, test and deploy dizmos will be upgraded from time to time. In such a case it may become necessary to update the relevant build scripts using dizmoGen (and Yeoman) again. Check the Upgrading the Build System section below about how to update your version of dizmoGen and the build scripts in your own dizmo project.
First, install Yeoman and generator-dizmo
using npm (we assume you have Node.js pre-installed):
npm install -g yo
npm install -g @dizmo/generator-dizmo
Note: On most operating systems the -g
option (shortcut for --global
) requires super user (administrator) rights. Due to security considerations however, avoid using such a privileged account and see the FAQ to be able to install global packages as a regular user.
Invoke the dizmo generator with a name of your choice, for example my-dizmo
and answer a few questions:
yo @dizmo/dizmo my-dizmo
After a successful build via npm run build
, drag and drop the ./build/MyDizmo-0.0.0.dzm
file onto dizmoViewer: You should see the front side of the dizmo with Hello World!
written on it. The name parameter is optional and can be changed at the prompt. Further, calling yo @dizmo/dizmo
is equivalent to invoking the default generator with yo @dizmo/dizmo:app
.
To list all possible arguments and options of the generator, enter:
yo @dizmo/dizmo --help
Npm uses a built in cache mechanism to accelerate package installation. There are various configuration options to control the behaviour of the cache. Here, we are interested in cache-min:
The minimum time (in seconds) to keep items in the registry cache before re-checking against the registry.
The provided default of 10
seconds is too short, to efficiently make use of caching. Therefore, we recommend setting it to for example to a day by running the configuration command:
npm config set cache-min 86400
By setting chache-min
to this value, you ensure that no package with a timestamp younger than a day is checked against the central registry for a possible update. This can significantly improve your npm experience.
Further, we suggest to clear the cache initially by running npm cache clean
, but this is not necessarily required: It will simply wipe out your cached packages, and ensure that no corrupted cache exists. However, this also means that your very first dizmo skeleton generation (and corresponding installation of npm packages) may take longer than later invocations. By running npm cache ls
you can determine, which npm packages have already been cached.
Note: It is recommended to clean the cache also before an update of the generator-dizmo
generator itself, by running npm cache clean
.
At the start, you will be asked a few questions, after which the terminal should look similar to:
yo @dizmo/dizmo
_-----_
| | .--------------------------.
|--(o)--| | Welcome to the awesome |
`---------´ | dizmo generator! |
( _´U`_ ) '--------------------------'
/___A___\
| ~ |
__'.___.'__
´ ` |° ´ Y `
? Name your dizmo: MyDizmo
? Describe it: My Dizmo
? And its bundle ID? com.example.my_dizmo
? What's your name? Name Surname
? And your email? name.surname@mail.net
The dizmo
generator asks you some questions – let's have a look at them:
? Name your dizmo: MyDizmo
If no dizmoName
argument is provided then by default MyDizmo
will be suggested: accept or change it as desired. This name will be used to create a project folder in the current director. For example, for the MyDizmo
name the folder will be my-dizmo/
.
? Describe it: My Dizmo
You should provide a short succinct description of your project. By default the name of the current dizmo will be taken as a base for a suggestion.
? And its bundle ID? com.example.my_dizmo
Each dizmo is required to have a unique bundle.identifier
, which is a name of the bundle each dizmo instance will belong to: For example, each sticky note dizmo would have the same com.dizmo.stickynote
bundle ID (but with different dizmo IDs). Choose as a prefix the domain of your company (in reverse notation with top level domain names like com
or org
preceding the rest), and then append a name related to the dizmo.
? What's your name? Full Name
Provide your full name, to designate yourself as the author of the project. By default, the current GIT user name – if available – or OS login will be used directly without actually prompting for the name. Otherwise, anything you enter here will be remembered and automatically used as the default on your next invocation of yo @dizmo/dizmo
.
The entry will be stored once the project skeleton is setup in package.json
under person.name
. For multiple contributors, see the npm:package.json documentation, section people-fields-author-contributors.
? And your email? my@email.net
Provide your email, so people can reach out to you for feedback, bug reports etc. By default the generator uses the GIT user email – if available – or the MAIL
environment variable.
The entry will be stored in package.json
under person.email
.
For multiple contributors, see again people-fields-author-contributors.
Since the build system of each dizmo is saved directly within a project, we need an upgrade mechanism of the former for an existing latter. But first, we have to upgrade generator-dizmo
by running:
npm upgrade -g @dizmo/generator-dizmo
Then within an existing project's main folder, we can execute:
yo @dizmo/dizmo --upgrade
It is also possible to only invoke yo @dizmo/dizmo
, in which case each and every conflict between the existing and new files and folders need to be manually signed-off by the user. Since all conflicts need to be decided on, instead of just the conflicts w.r.t. the build system, this manual upgrading can be onerous. However, with the yo @dizmo/dizmo --upgrade
command, only the build system of the actual project is upgraded, while the non-build related files and folders remain (mostly) untouched.
After you have answered the last question, the generator will create the project's skeleton. If you have the tree
command installed on your operating system, then you can visualize the directory structure with:
tree
.
├── .eslintrc.json
├── assets
│ ├── Icon-dark.svg
│ ├── Icon.svg
│ ├── locales
│ │ ├── translation.de.json
│ │ └── translation.en.json
│ └── Preview.png
├── gulp
│ ├── package.js
│ ├── tasks
│ │ └── *
│ └── tools
│ └── *
├── gulpfile.js
├── help
│ └── en
│ ├── help.md
│ └── placeholder-400x275.png
├── jsdoc.json
├── LICENSE
├── package.json
├── README.md
├── source
│ ├── index.html
│ ├── index.js
│ ├── lib
│ │ └── i18n-*.min.js
│ └── style
│ └── style.scss
├── test
│ └── test.js
└── webpack.config.js
Let's have a look at each ot the top level files and directories:
-
.eslintrc.json
: a JSON file, which can be used to configure the linting process for the JavaScript code; see eslint.org/docs/user-guide/configuring for further information. -
assets
: A folder containing asset files like images, which can be accessed from within the dizmo using a relative path likeassets/Preview.png
. Put any such files (or media) which are not directly related to styling into this folder. You can also create sub-folders or any nested directory structure according to your needs. One such folder isassets/locales
where JSON files for translation purposes can be found. -
gulp
: A folder containing a build system based on gulp. If you are familiar withgulp
, then you can change the build mechanism according to your needs; otherwise, just use it as it is. -
gulpfile.js
: The main script driving thegulp
build system; usually you can leave this file as it is. -
help
: Once you have developed your dizmo, you might want to provide user documentation, which can be placed in this folder. -
jsdoc.json
: Configuration file to be used by the integrated documentation system. -
LICENCE
: By default an ISC (Internet Software Consortium) license is generated, which is functionally equivalent to the simplified BSD and MIT licenses, but with a simpler language. Leave or change this according to your needs. -
package.json
: This is an important file! It is consumed by the npm package manager, provides run scripts for the build system (likelint
,clean
,build
,install
etc.), and allows to change the dizmo settings. Have a look below at the corresponding section for further information. -
README.md
: A simple shortened version of this README.md; it is meant to provide a quick overview, and can then be replaced with a project specific content. -
source
: A folder containing your own scripts for your dizmo, likeindex.html
andindex.js
plus style sheets understyle/
, which use by default SASS. Further, in thesource/lib/
folder you can put third party libraries, which you can then directly reference via a<script>
tag in theindex.html
markup. -
test
: A folder containing your test cases. -
webpack.config.js
: project wide configuration file for the webpack bundler.
Dizmos use npm as a package manager; to thoroughly understand its functionality, please consult "What is npm?" and work through the 15 small video based tutorials in the Getting Started section.
In addition to the default entries of npm the package.json
file contains a dizmo
section:
"dizmo": {
"settings": {
"attributes": {
"settings/usercontrols/allowresize": true
},
"bundle-identifier": "com.example.my_project",
"bundle-name": "My Project",
"category": "",
"height": 360,
"tags": [
"my-project"
],
"width": 480
},
"store": {
"host": "https://store-api.dizmo.com"
}
}
And here is a list of available options:
-
settings
: any entry provided here will be translated to an entry inbuild/Info.plist
, which is the main control file defining the properties of a dizmo. Two properties, that you might also need to set, areapi-version
andelements-version
. If you want to downgrade the generated skeleton, so that it is compatible with older versions of dizmoViewer, you would set them for example to1.3
and1.0
respectively. Theattributes
object allows you to set attributes of a dizmo even before the JavaScript gets executed. For a full list of all the attributes that can be set please refer to the data tree page in our documentation. -
store
: configuration entries required bynpm run upload
, which needsstore/host
(by default pointing tohttps://store-api.dizmo.com
),store/user
andstore/pass
. The latter two should not be directly set inpackage.json
but instead via the default configuration (see below), to avoid the store credentials getting accidentally committed to a version control system.
The dizmo
section in package.json
can be extended with default values, which have to reside in .generator-dizmo/config.json
(in any of the parent directories):
{
"dizmo": {
"deploy-path": "..", "store": {
"host": "https://store-api.dizmo.com",
"user": "..",
"pass": ".."
}
}
}
The configuration is hierarchical and recursive, meaning that a .generator-dizmo/config.json
file can be saved in any parent directory of the current project, all of which are then merged during the build dynamically into package.json
, where configuration values from files in the lower levels (meaning closer to package.json
) have precedence.
As an alternative to .generator-dizmo/config.json
the .yo-rc.json
file can be used to store default configuration values; see the managing configuration section for further information.
Before running any script, please ensure that
npm install
has been executed, and that the dependencies beneathnode_modules
are up to date!
Please read first about npm#scripts – in each package.json
the following scripts are available:
-
clean
: completely removes the./build
sub-directory.
npm run clean
-
deploy
: builds and installs the dizmo to a installation path given by thedizmo/deploy-path
configuration entry inpackage.json
(or better in.generator-dizmo/config.json
):
npm run deploy
-
deploy
: ..or if theDZM_DEPLOY_PATH
environment variable has been defined, then the dizmo is copied to the corresponding location.
DZM_DEPLOY_PATH=/path/to/my/dizmos npm run deploy
-
lint
: applies linting to your source code using ESLint, which can be configured via the.eslintrc.json
file.
npm run lint
-
build
: builds the dizmo (including the*.dzm
artifact) from scratch and puts it into the./build
sub-directory.
npm run build
-
build
: ..or if theDZM_UPGRADE_CHECK
environment variable has been defined, then the dizmo is build accordingly with or without the upgrade check.
DZM_UPGRADE_CHECK=false npm run build
-
test
: ensures to run tests – returns and error code of0
for success and1
for failure.
npm run test
-
docs
: generates documentation in the./docs
sub-directory by using in-source comments.
npm run docs
-
watch
: watches your source code, and incrementally (and quickly!) rebuilds the dizmo on any change.
npm run watch
-
watch
: ..further, it copies the build to the installation path, if either thedizmo/deploy-path
configuration has been set inpackage.json
(or better in.generator-dizmo/config.json
) or theDZM_DEPLOY_PATH
environment variable has been provided.
DZM_DEPLOY_PATH=/path/to/my/dizmos npm run watch
-
upload
: uploads a*.dzm
artifact to the dizmoStore requiring ahost
anduser
name plus a validpass
word. They can be set via thestore/host
,store/user
andstore/pass
entries inpackage.json
(or better in.generator-dizmo/config.json
) or via theDZM_STORE_HOST
,DZM_STORE_USER
andDZM_STORE_PASS
environment variables.
DZM_STORE_USER="username" DZM_STORE_PASS="password" npm run upload
The build process supports command line arguments: It is important to realize that this CLI support is directly integrated via the underlying primitives, for example linting can be enabled or disabled via --lint
or via --no-lint
, and this argument can be provided to any script which depends on the linting step.
In many cases the arguments are boolean flags which can enable or disable a certain build step (like linting or minification). But many can also accept specific configuration objects – like JSON: For example, the linting of JavaScript is controlled via an eslint specific configuration object.
However, for the daily usage the default settings should be more than enough: Simply using the CLI arguments as boolean flags to enable or disable a particular step will do the job. Further, please notice that when you for example disable linting, then during the build the corresponding step will still be shown, but it will not perform any actual linting!
On the command line linting can be enabled by providing --lint
(which is the case by default), and it can be disabled by providing --no-lint
. Hence, the following will lint and build the dizmo:
npm run build
To stop the build engine from linting, it can directly be overridden on the CLI:
npm run build -- --no-lint
The double hyphen after npm run build
is necessary, since it tells NPM to forward the --no-lint
argument to each build sub-step, which combined will build the dizmo. If you do not like the four consecutive hyphens, you can provide the script name also after the initial double hyphen:
npm run -- build --no-lint
Or more verbosely, below you see in its clearest form how the build
script is run with the additional argument of --no-lint
:
npm run-script -- build --no-lint
Conversely, if you explicitly want to enforce linting then you can execute:
npm run -- build --lint
As mentioned, this is in general not required since linting is by default on. However, if you are not sure if this is the case ‐ for example, when you are putting together a build environment and want enforce linting ‐ then providing the --lint
flag explicitly makes sense.
The specific configuration objects for controlling eslint, coffeelint and tslint can be looked up via their respective documentation. Below some very simple examples have been shown, to demonstrate the corresponding capability to override the defaults.
- Enforce for a JavaScript based dizmo project linting, but ignore unused variable names:
npm run build -- --lint='{"rules":{"no-unused-vars":0}}'
- Enforce linting, but provide a warning w.r.t. unused variable names:
npm run build -- --lint='{"rules":{"no-unused-vars":1}}'
- Enforce linting, but provide an error w.r.t. unused variable names:
npm run build -- --lint='{"rules":{"no-unused-vars":2}}'
Above, in case of an error the build process will not fail, effectively making it equivalent to a warning. If such behaviour is not desired, then the lint.js
gulp task should be modified to stop the build process upon a linting error.
Providing the --minify
option on the CLI will ensure that the scripts, styles and markup are automatically minified:
npm run build -- --minify
Please notice, that by default source maps are not created – to avoid accidental leaks of potential intellectual property. However by appending the --sourcemaps
flag they can be enabled:
npm run build -- --minify --sourcemaps
It is also possible to suppress a minification:
npm run build -- --no-minify
Further, since minification consists of five sub-steps, namely (a) markup minification, (b) style minification, (c1) script obfuscation plus (c2) minification and also (d) source maps generation -- where (c1) and (d) however need to be explicitly enabled -- it is possible to control them independently of the general --minify
flag:
npm run build -- --minify --closure --htmlmin --sass --no-obfuscate --no-sourcemaps
The above set of arguments is (given default webpack.config.js) equivalent to the --minify
flag. Further, each of them can be negated as well:
npm run build -- --no-minify --no-terser --no-htmlmin --no-sass --obfuscate --sourcemaps
Further, each flag can accept an optional configuration object to control in detail the corresponding minification, obfuscation and source map generation steps:
- Minify the scripts; see webpack-mode for further information w.r.t. to the configuration:
npm run build -- --minify='{"mode":"production"}'
- Minimize the scripts; see webpack-closure-plugin for further information w.r.t. to the configuration:
npm run build -- --minify --terser='{"keep_fnames":true}'
- Minimize the markup; see gulp-htmlmin for further information w.r.t. to the configuration:
npm run build -- --minify --htmlmin='{"collapseWhitespace":true}'
- Minimize the styles; see gulp-sass for further information w.r.t. to the configuration:
npm run build -- --minify --sass='{"outputStyle":"compressed"}'
- Obfuscate the scripts; see webpack-obfuscator for further information w.r.t. to the configuration:
npm run build -- --minify --obfuscate='{"compact":true}'
- Create source maps for the scripts and the styles (in
package.json
each source map generation can be configured separately, however on the CLI there is only a single flag to control both); see gulp-sourcemaps for further information w.r.t. to the configuration:
npm run build -- --minify --sourcemaps='{"loadMaps":true}'
In general, using --minify
(or --no-minify
) combined with the --sourcemaps
(or --no-sourcemaps
) CLI options should be enough. Only if explicit control is required, using the --htmlmin
, --sass
or --obfuscate
flags is necessary. Further, providing configuration objects to these flags should only be done, when you know what you are doing (or are not happy with the provided defaults).
A dizmo project uses webpack to control how a dizmo is bundled – using webpack.config.js, which in general can be left as it is! However, if the need should arise to modify the bundling process, then either webpack.config.js can be modified directly, or (in case no permanent change is desired then) the --webpack
CLI option can be utilized. For example, to disable the babel-loader
module on the fly one could run:
NO_BABEL_JS='{"module":{"rules":[]}}' ## or: '{"module":{}}'
npm run build -- --webpack="$NO_BABEL_JS"
NO_BABEL_CS='{"module":{"rules":[{"test":"/\\\\.coffee$/i","loader":"coffee-loader"}]}}'
npm run build -- --webpack="$NO_BABEL_CS"
NO_BABEL_TS='{"module":{"rules":[{"test":"/\\\\.tsx?$/i","use":"ts-loader"}]}}'
npm run build -- --webpack="$NO_BABEL_TS"
...where it's recommended to export the NO_BABEL_JS
, NO_BABEL_CS
and/or NO_BABEL_TS
constants in one's shell environment – if they are used often. These constants can be derived, by modifying the webpack.config.js
as one sees fit, and then converting the relevant portions into a minified JSON format.
Dizmo offers a dizmoStore where dizmos can be uploaded to: Besides package.json
(or .generator-dizmo/config.json
) and environment variables, upload arguments like the host and user name plus password can also be provided via the CLI:
npm run upload -- --host=https://store-api.dizmo.com --user='..' --pass='..'
By default npm run upload
tries to upload and publish an uploaded dizmo. However, it is possible to skip the publication step by running:
npm run upload -- --no-publish
And then only in a subsequent step to publish it:
npm run upload -- --publish
However the command above assumes, that the actual upload has already been performed! Hence, executing it without having previous uploaded a dizmo will fail, since there would be no uploaded dizmo to publish.
Once your dizmo is build, a build/
folder with the following structure is created:
tree build/
build/
├── MyDizmo
│ ├── Icon-dark.svg
│ ├── Icon.svg
│ ├── Info.plist
│ ├── Preview.png
│ ├── assets
│ │ └── locales
│ │ ├── translation.de.json
│ │ └── translation.en.json
│ ├── help.zip
│ ├── index.html
│ ├── index.js
│ ├── lib
│ │ └── i18n-*.min.js
│ └── styles
│ └── styles.css
└── MyDizmo-0.0.0.dzm
-
MyDizmo-0.0.0.dzm
: A ZIP archive of theMyDizmo
folder with a version suffix, which has been defined inpackage.json
. Please see semantic versioning and npm for further information.In dizmoViewer (desktop edition) only the dizmo bundle with the highest version number is cached! Therefore, it is important to increase the version, when releasing a dizmo to your audience. However, simply changing the version suffix in the
*.dzm
file name will not work: The version is required to be set inMyDizmo/Info.plist
(which happens automatically based on the version information inpackage.json
). -
MyDizmo/Info.plist
: a list of properties (in XML notation) defining a dizmo. This file is derived from the original.info.plist
template, which has been enriched with information frompackage.json
. -
MyDizmo/assets
: a copy of the originalassets
folder; -
MyDizmo/help.zip
: a ZIP archive of the originalhelp
folder; -
MyDizmo/index.html
: the main HTML script; -
MyDizmo/index.js
: the main JavaScript bundle; -
MyDizmo/lib/i18n-*.min.js
: i18n internationalization wrapper; -
MyDizmo/styles/styles.css
: cascading stylesheets.
By dragging and dropping the MyDizmo-0.0.0.dzm
artifact onto dizmoViewer a corresponding dizmo can be instantiated. If it has not been already installed, it will get installed to the default location as well.
Once you have accommodated yourself with some basic dizmo development, you can go further and try out the dizmo:sub-coffeescript
and dizmo:sub-typescript
sub-generators. For CoffeeScript projects use:
yo @dizmo/dizmo --git --coffeescript
And for TypeScript projects use:
yo @dizmo/dizmo --git --typescript
Further, there are sub-generators for other projects (like @dizmo/generator-dizmo-react and @dizmo/generator-dizmo-vue); search the NPM registry for generator-dizmo
to get a list of possible sub-generators.
Invoke a generator combined with the --git
option:
yo @dizmo/dizmo my-dizmo --git
The created project folder will now be named my-dizmo.git
, and it will be initialized as a GIT repository – no commits will be performed though. Further, this only will work if the git
command is accessible.
All (sub-)generators support dependency management using Node modules: You can structure your dizmo code using require
statements plus the exports
and module.exports
objects. Using the more modern import
and export
statements is also possible. Additionally, you can install external third party libraries and reference them directly with require
or import
. For example, to use jQuery
run:
npm install jquery
Then in your code you can get a reference with:
const $ = require('jquery');
Or better with:
import $ from 'jquery';
If you want to remove an installed library just run:
npm remove jquery
This approach works well, as long as the external libraries are not too large, since otherwise the build process may take longer. In such cases you should use the incremental builder using the watcher:
npm run watch
Or you can simply drop a library into the source/lib/
sub-directory and reference it via a corresponding <script>
tag in the index.html
markup.
If npm install
is not run before attempting to build a dizmo, then a message similar to the one below might be produced:
error argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "build"
error code ELIFECYCLE
error MyDizmo@0.0.0 build: `node ./node_modules/gulp/bin/gulp.js`
error Exit status 1
error Failed at the MyDizmo@0.0.0 build script 'node ./node_modules/gulp/bin/gulp.js'.
In such a case, just run npm install
to ensure that all the required dependencies get installed locally.
You have to set up npm
for global installations, since yo
should neither be installed nor run with sudo
. The preferred approach here is to enable npm
to install packages globally without breaking out of the $HOME
folder, by setting a local node
prefix
. This is achieved for example by running
echo 'prefix = ~/.node' >> ~/.npmrc
in your local shell. After that the $PATH
environment variable needs to be modified as well, to point to the new installation destination for the global node
executables, by adjusting your favorite shell's configuration – for example use:
export PATH="$PATH:$HOME/.node/bin"
in your ~/.bashrc
. After that, you can happily run npm install -g yo
without sudo
and without running into potential permission conflicts. Further, later-on if something gets completely broken and you want to start from scratch, all you need to do is to remove your ~/.node
directory.
The Yeoman toolkit very strongly discourages the usage of any generator based on it to be run as root. Hence, you will get the following error:
sudo yo @dizmo/dizmo --help
/usr/lib/node_modules/yo/node_modules/configstore/index.js:53
throw err;
^
Error: EACCES: permission denied, open '/root/.config/configstore/insight-yo.json'.
You don't have access to this file.
The same error is thrown, when you run sudo yo -h
as well. Also, the behavior is independent of the usage of sudo
or directly being logged in as root. Please see the answer to the previous question to be able to use yo
without sudo
.
At its core, webpack is a static module bundler for modern JavaScript applications. The dizmo generator creates projects which can then be configured by editing the webpack.config.js file. See webpack.js.org/concepts for an introduction to basic concepts like entry, output, loaders, plugins, mode and browser compatibility.
The graphical user interface of Windows does not allow to create a folder named .generator-dizmo
: However it is possible to create one via the command line interface. For example using the Windows PowerShell one can run:
PS C:\Users\user> mkdir .generator-dizmo
Such files are device dependent and hence should be ignored globally on the developer's device, instead on a per project basis. See How to Remove .DS_Store File from a Git Repo on Mac OS X for an excellent discussion of the issue. Also see ignoring files to learn about setting up a global ignore list.
Older versions of the TypeScript generator were not creating an index.ts
script, but newer ones do. However, if an older project is upgraded then the index.ts
is not post-generated, because it might be that the main entry script of the original project has changed. Introducing a heuristic to automate this (meanwhile rare) edge-case has been avoided. Just manually creating an index.ts
with usually the following content should resolve any corresponding build problems:
export { App } from './app/app';
The npm tool offers the npm audit
and npm audit fix
commands, which scan your project for vulnerabilities and automatically install any compatible updates for corresponding dependencies. Run npm help audit
to get an in-depth description about this tool.
© dizmo AG, Switzerland