Deprecate directories.lib

[matthewp]

directories.lib is a confusing feature for developers. When seeing a module specifier like:

require("package/foo/bar");

It assumes that this module is located at PACKAGE_ROOT + "/foo/bar". This makes it hard to understand code as an outside developer (or designer).

Additionally directories.lib makes it hard to do stuff like have different folders for your source and tests:

src/
test/

test/test.js

require("../src/widget");

The above can cause things to break in subtle and hard to debug ways.

[justinbmeyer]

A few thoughts on this (in order of priority) (( I agree it's a confusing feature ))

ES Modules Transpiled so they work everywhere

Withoutlib, how can we make it easy to develop ES plugins that need to be transpiled AND exporting them in a reasonable way so they can be loaded by other module loaders?

Afaik, directories.lib is really important for making that workflow nice. If we eventually migrate something like CanJS to this workflow we will need it.

I think we need to think through what bit-tabs looks like w/o directories.lib

Keeping JS out of all the config stuff

This might affect apps like PMO negatively:

https://github.com/donejs/place-my-order

The root folder would either contain everything w/i the root folder and the src folder as follows:

Or we force a src almost every module name.

I think we should "hide" it for now

IMO, I think this proposal at least belongs w/i DoneJS's app generator first. There, we hide that this even exists, and see how it goes. (We might need to keep it around for the plugin generator (far less used) unless there's a good way to address the first point).

I think we need to know how many apps are like PMO (use and benefit from lib) and how many are like Bitballs that don't need it / use it b/c there's a separate public folder that has an independent package.json.

[matthewp]

Just to note, this issue is not an RFC. An RFC would be submitted as a pull-request to this repo. I added the issue to remind myself to create an RFC some time in the future. Just noting this in case it's not obvious. Anyone is free to discuss the issue here, of course.

Thanks for the feedback. I will address these counterpoints when writing the full RFC (the template has an impact section to address downsides).

I think we need to know how many apps are like PMO (use and benefit from lib) and how many are like Bitballs that don't need it / use it b/c there's a separate public folder that has an independent package.json.

Personally, I don't see much benefit for apps. Map configuration works just as well for apps. The main benefit is for libraries and their ability to reference themselves. Personally:

1) I wouldn't want to write a library this way since it makes the code non-portable. 2) I don't have a lot of sympathy for not wanting to write ../../ for lib authors.

IMO, I think this proposal at least belongs w/i DoneJS's app generator first.

Prioritizing non-Steal projects prevents Steal from evolving at an acceptable pace. Steal should take other projects' needs into consideration, of course, but it isn't (shouldn't be) subservient to them. If DoneJS prefers directories.lib it can be implemented via a configDependencies extension.

[justinbmeyer]

The main benefit is for libraries and their ability to reference themselves.

The main benefit isn't about ../../ (even though you must have some sympathy because ~ was added).

The main benefit is that I could develop can-define in ES6, but have can-define/map/map work everywhere. AFAIK, directories.lib is the only way to support this easily.

In development:

src/
  map/
    map.js (ES6)

What's pushed out to npm:

src/
  map/
    map.js (ES6)
map/
  map.js (CJS / ES5)

StealJS users would still load src/map/map.js, but everyone else would get map/map.js.

Having StealJS users still load src/map/map.js is nice because it allows you to change the source code in an npm-linked package and have it work w/o having to run a build.

[matthewp]

One way I've seen projects deal with that problem is to build out the preferred folder structure as part of their release process. For example you could do a build into dist and then copy over the package.json and any other files, then cd into the folder and run npm publish from there.

[justinbmeyer]

Doesn't this still require a build then? One wouldn't be able to change a npm linked source file to test at least the steal version out.

Sent from my iPhone

On Mar 26, 2017, at 5:35 PM, Matthew Phillips notifications@github.com wrote:

One way I've seen projects deal with that problem is to build out the preferred folder structure as part of their release process. For example you could do a build into dist and then copy over the package.json and any other files, then cd into the folder and run npm publish from there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[matthewp]

No, it wouldn't require a build for testing. You would npm link the repo folder to test ES201x files, then build+publish ES5 files.

[matthewp]

Here's another issue caused by directories.lib. If not for directories.lib, the tilde alias could just be a regular ole map config.

This makes me think that directories.lib mostly is for libraries. In this case, I wonder if proper packages configuration could replace it. packages config would accept any configuration values but would only be applied from a parent within the package.

[matthewp]

I've added an RFC for package configuration. This change would eliminate the need for directories.lib (as far as I can think of), by allow contextual maps within a package, which serves the same purpose but is more powerful / more generic.

If accepted I'll create an RFC for directories.lib removal.

[matthewp]

Issue moved to stealjs/steal #1437 via ZenHub