@toorieaa/auth-app-session-options

• 1. Publishing npm packages
• 2. More about peerDependencies
• 3. How to use?
  • 3.1. Creating your own module.
  • 3.2. Publishing the module and using the options in a project
    • 3.2.1. Explanation
  • 3.3. Using in your end project
• 4. Important GOTCHYAS
• 5. Motivation
  • 5.1. License

1. Publishing npm packages

https://docs.npmjs.com/creating-and-publishing-scoped-public-packages

2. More about peerDependencies

https://www.youtube.com/watch?v=0l9YLCk0wOo

3. How to use?

How do use this?

3.1. Creating your own module.

Creating your own module.

• Create a new node project with the appropriate scope. See #1 and #2 for more information on this.
• Determine if you want your module to be in a personal repository, or in a corporate repository
• Determine if you want the access of your module to be public or restricted
• Verify your package json looks like the following. Make note that the below peerDependencies are added to extend functionality. These are : sessionoptions. The below are the minimal settings needed to be inserted into the package.json. Insert your own version number, and make sure the scope and name are correct.

{
  "name": "@toorieaa/auth-app-session-options", //<--- verify you did npm init with the correct scope/name
  "version": "0.0.1", //<---- insert your version
  "type": "module", //<--- required
  "peerDependencies": { //<-- required, used to extend functionality
  "@toorieaa/sessionoptions": "^2.0.0" //<-- required
}//<-- required
}

• Create a index.js file

import SessionOptions from "@toorieaa/sessionoptions";

const override = Object.create(SessionOptions);
override.SESSION_CRYPTO_SESSION_LENGTH = 50;

export default override;

3.2. Publishing the module and using the options in a project

In your project you need to install and import your new overridden session options (the recently published package)

• Install sessionoptions as a dependency
• Install singletonclasserror as a dependency
• Install your recently published module as a dependency, which expects sessionoptions and singletonclasserror to be present in the project, since sessionoptions has a peerDependency of singletonclasserror. More information on that here https://til.hashrocket.com/posts/vkavn42wdk-list-peer-dependencies-using-npm

npm i @toorieaa/sessionoptions
npm i @toorieaa/singletonclasserror
npm i //<your module scope and name in the correct format>

3.2.1. Explanation

• The first install command : a required peer dependency. The base sessionoptions peerDependency
• The second install command: a required peer dependency. A peer dependency of @toorieaa/sessionoptions. https://til.hashrocket.com/posts/vkavn42wdk-list-peer-dependencies-using-npm
• The third install command : your published dependency, change the name

3.3. Using in your end project

import OverriddenSessionOptions from "@toorieaa/auth-app-session-options";

4. Important GOTCHYAS

The npm property key "private" will only prohibit npm from publishing a package if set to true, regardless of any other parameters. This key expects a boolean value and is optional, but defaults to false. This property key / value pair has nothing to do with the access you grant your module, rather, if you or your team attempts to publish a package in any way, and this key is set to true, npm will not publish the package.

Use this key to prevent packages from accidentally being published. Use it to prevent a accidental publish to a package you would not want to publish at all, whether access is public or restricted, or whether the scope is personal or corporate and under any circumstance.

5. Motivation

• Modularization can help abstract complex components away to keep projects focused on their business use cases.
• Modules can be reused across projects
• You can extend the functionality of modules, and have projects depend on those extensions. Note that it is probably not a good idea to pin projects on certain versions of a module, as pinning a project in general for this case allows for your project to never consume important or critical updates for software dependencies. For this reason it is a good idea to extend the functionality of a module per project, and allow that project to consume version updates on this new extended dependency. That way, you can perform critical updates to certain applications, and also provide configuration changes in the process
• You can in some cases create less complex projects, by forgoing the use of webpack as a bundler, and create common functionality modules that have highly used, highly tested, and highly consistently functionality. This is the same reason why code on stack overflow might be good code. That code is sometimes highly tested, and used across many different products. The individual products using them act as their own additional unit and integration tests compounded by any additional testing efforts. For all the webpack users out there, please don't take that as a bad thing.
• You can create tests that test those modules
• Having products that are simple and run out of the box without large amounts of effort, allows for an even higher dimension of customizability, compounded by the rate of effort. Not only to the project's configuration itself, but to the code complexity and design as a whole.
• This type of modular abstraction and encapsulation is inspired by polymorphism and inheritance in OOP-first languages

5.1. License

[MIT]