Naming things!

@dbouwman @jgravois @noahmulfinger @dmfenton @araedavis @ajturner I think we need to discuss standardizing naming of our packages.

Currently we have 1 package called arcgis-core. This seems way to general to me. I would propose:

• arcgis-rest-client-js - this would mean all our packages would be arcgis-rest-client-js-*. Kinda long.
• arcgis-rest-js - this would mean all our packages would be arcgis-rest-js-*. Kinda long.
• @esri/rest -client - no need to use js in the NPM and package names. npm install @esri/rest-client-core.

Come up with something else like Koop, Winnow, Terraformer, ect… I’ve pulled from architectural terms before so I’ll suggest some:

• truss - taken on npm. Could do arcgis-truss
• quoin - abandoned name from my first attempt at a Dojo based framework.
• arris - A modem company, but also unclaimed on NPM.
• trestle - also taken on NPM could do arcgis-trestle

[tomwayson]

@patrickarlt also from the npm docs:

Each npm user/organization has their own scope, and only you can add packages in your scope. This means you don’t have to worry about someone taking your package name ahead of you. Thus it is also a good way to signal official packages for organizations.

That last sentence gives me the impression that it’s equally valid to use scopes as a way for an organization to publish their official packages, even if they’re unrelated. Generally feels to me like the notion of using scopes for related packages was more important before monorepos started to become more common.

So, regardless of the final names, I think we should use scoped packages.

I know I’m in the minority on this point, but generally, as much as I ❤️ @esri/boutique, I prefer names that try to tell you the lib actually does rather than names based on trees, or esoteric terms that I have to look up to know what they mean. I know that makes for boring, forgetful names. That’s just my 2 cents, and I’ll defer to whatever y’all want.

@jgravois made a really good point re: how a-js prefix is useful for an Esri org repo name, but redundant (implied) for npm packages. So I like his proposed (non-Beastie Boys) names. The only change, if any, that I would consider is what do to about the “core” package. By removing -core, it kind of feels to me that that package rolls up the other ones, like you could just npm i @esri/rest and you get a single lib that includes all of them. Really it’s the opposite, that package is a dependency of the others. I can go both ways on that. I think a lot of prior art informs our expectations. For example babel-core tries to makes it clear that you probably need more libraries to do anything useful, but maybe they had to do that to just to draw a distinction from the previous versions that were “batteries included.” If the objection to -core is that it doesn’t tell you enough about what the package actually does, then how about @esri/rest-request? So:

github.com/Esri/rest-js
npmjs.com/package/
  @esri/rest-request
  @esri/rest-auth
  @esri/rest-portal
  @esri/rest-server
  @esri/rest-geocode

If your app only needs to talk to ArcGIS Online, my expectation would be that you could just npm i @esri/rest-portal and it would install the deps it needs (i.e. @esri/rest-request). Kind of veering into #5 territory here, but I think an ideal goal would be that @esri/rest-auth is not a dependency of the other packages. For example, if someone only wanted to interact w/ public facing services.

[tomwayson]

I, for one, think that Esri should make a low level JS library that is a wrapper for our REST APIs as an official product. I think that’s what people should find when people search for “Esri” or “ArcGIS” and “JavaScript” and that the first line should say, if you want to make a map w/ this stuff, see either the JSAPI or esri-leaflet. If you want to make a 3D visualization, see the JSAPI. They use this stuff under the hood.

But that’s just me, and I’m just an old hippie that sold out to the man.