Better package structure for require commands

[prasadtalasila]

Description

The sub-directories must contain better package.json files so that the require() can allow us to directly import the targeted sub-module.

Steps to Reproduce

Expected behavior: [What you expect to happen]

Actual behavior: [What actually happens]

Reproduces how often: [What percentage of the time does it reproduce?]

Additional Information

[prasadtalasila]

I have a few ways to go about it :

• Various other hacks https://gist.github.com/branneman/8048520
• Package.json : https://glebbahmutov.com/blog/subfolders-as-dependencies/
• Rooty Library: https://www.npmjs.com/package/rooty
• https://stackoverflow.com/a/45076616

The suggestions made by branneman seem better. Of the alternatives given, the alias and startup script seem close to what we are doing in other places in AutolabJS project. Of course, we need to make the alias work with the linting and test setup.

[prasadtalasila]

The problem requirements

• remove relative paths
• application-level configurability of view
• interface-level (object-level) compatibility between the views
• dependency injection of view into controller
  • Right number of view objects -- not one global view, or not too many small view objects
• Application working both as a standalone cli and also as a library-level dependency

[prasadtalasila]

@ishitamed19 and @mukkachaitanya

There is a tutorial on require which is relevant to this issue. Node.js also allows require.resolve() function which allows us to specify the path names of resolution. We can construct the path name based on the view taken from a config file and give that as an option to require.resolve() function. The require.resolve() function gives us the full path name of the module which can be used to load the module. See a simplistic tutorial here

Also there is now ES6 modules which are supported on Node.js via esm. ES6 modules are like Java packages which provide a nice design flexibility. Another side benefit is the destructuring of necessary named imports from an ES6 module. The only disadvantage vis-a-vis commonJS modules (require()) is that we can't have imports from dynamic paths. Here is a brief summary.

[prasadtalasila]

It might be prudent to just target the following changes.

• remove relative paths
• application-level configurability of view

The rest of the requirements demand deep design changes. We can take them up later.

[prasadtalasila]

The solution of putting something in package.json would limit us from configuring a view. Instead, if we create a require.js in utils which uses the wrapper idea, then we can simply use the following functions.

• viewRequire()
• modelRequire()
• utilsRequire()

We can still read the view from configuration and use require.resolve() to identify the right view files.