Document - 17/03/2020

gistfile1.txt

Import / Export
2.a Modules
+ In Javacript, the Modules is refer to small units of indenpendent,
reusable code. It use for design patterns and very necessary when we
building any Javascript application.
+ Sometime, the modules are functions, objects, classes or variables
available to the outsite world that is exporting and importing them
where we need in other file.
--------------------------------------
3
NPM
3.a NPM public
+ Publishes a package to the registry so that it can be installed by name. All files in the
package directory are included if no local .gitignore or .npmignore file exists. If both files
exist and a file is ignored by .gitignore but not by .npmignore then it will be included
+ By default npm will publish to the public registry
npm publish [<tarball>|<folder>] [--tag <tag>] [--access <public|restricted>] [--otp
otpcode] [--dry-run]
+ Describe
* <folder>: A folder containing a package.json file
* <tarball>: A url or file path to a gzipped tar archive containing a single folder
with a package.json file inside.
* [--tag <tag>] Registers the published package with the given tag, such that `npm
install @` will install this version. By default, `npm publish` updates and `npm
install` installs the `latest` tag. See `npm-dist-tag` for details about tags.
* [--access <public|restricted>] Tells the registry whether this package should be
published as public or restricted. Only applies to scoped packages, which default
to restricted. If you don’t have a paid account, you must publish with --access
public to publish scoped packages.

* [--otp <otpcode>] If you have two-factor authentication enabled in auth-and-
writes mode then you can provide a code from your authenticator with this. If you

don’t include this and you’re running from a TTY then you’ll be prompted.
* [--dry-run] As of npm@6, does everything publish would do except actually
publishing to the registry. Reports the details of what would have been published.
+ Fails if the package name and version combination already exists in the specified registry.
+ Once a package is published with a given name and version, that specific name and
version combination can never be used again, even if it is removed with npm-unpublish.
3.b NPM scripts
+ We may encounter the following problems with use build tool: There isn’t a plugin for
the package you want to use, The plugin is out of date and doesn’t support the underlying
package properly, The plugin doesn’t support a feature you’d like to use for the underlying
package, The plugin documentation is lacking or unclear, The plugin doesn’t handle errors
well,.. Because each build tool has its own opinion about the way things should be done
and that means that each tool comes with its own quirks and gotcha’s that need to be
learned. A simple solution to these problems would be to remove the (sometimes complex)
abstraction of build tools altogether and run the underlying packages manually on the
command-line and NPM scripts solve that problem
+ Npm has a run command that can run scripts defined in the scripts property of
a package.json file.
3.c NPX
+ Executes <command> either from a local node_modules/.bin, or from a central cache,
installing any packages needed in order for <command> to run.
+ By default, npx will check whether <command> exists in $PATH, or in the local project
binaries, and execute that. If <command> is not found, it will be installed prior to
execution.
+ Unless a --package option is specified, npx will try to guess the name of the binary to
invoke depending on the specifier provided. All package specifiers understood
by npm may be used with npx, including git specifiers, remote tarballs, local directories,
or scoped packages.

+ If a full specifier is included, or if --package is used, npx will always use a freshly-
installed, temporary version of the package. This can also be forced with the --ignore-
existing flag.

3.d References
+ NPM PUBLISH: https://zellwk.com/blog/publish-to-npm/ ,
https://docs.npmjs.com/creating-and-publishing-scoped-public-packages
+ SCRIPT: https://deliciousbrains.com/npm-build-script/ ,
https://www.freecodecamp.org/news/introduction-to-npm-scripts-1dbb2ae01633/
+ NPX: https://www.npmjs.com/package/npx
----------------------------------
4
Sematic versioning
4.a Sumary
+ MAJOR version when you make incompatible API changes,
+ MINOR version when you add functionality in a backwards compatible manner, and
+ PATCH version when you make backwards compatible bug fixes.
+ Additional labels for pre-release and build metadata are available as extensions to the
MAJOR.MINOR.PATCH format.
4.b Patch
+ Patch updates are interchangeable, meaning consumers can upgrade or downgrade freely.
Content: Internal fix
Example: Bug fix, Performance improvement, environment or internal tweaks
Policy: Consumers should update their software without hesitation
4.c Minor
+ Minor updates are backward compatible, meaning consumers can upgrade freely.
Content: Interface change with full backward compatibility
Example: New feature, Endpoint declared deprecated
Policy: Update your software to get some new features. Nothing will break
4.d Major
+ Major updates are non-compatible, meaning consumers can not upgrade without changing
their software where applicable.
Content: Interface change breaking backward compatibility
Example: Change API endpoint name or signature, Remove an endpoint
Policy: Test your system extensively post update. Migration documents may be in order
4.e References
+ https://medium.com/fiverr-engineering/major-minor-patch-a5298e2e1798
+ https://semver.org/