search

CartoDB / toolkit

JS library to interact with CARTO APIs in a simple way
https://toolkit-wheat.now.sh
BSD 3-Clause "New" or "Revised" License
9 stars 3 forks source link

Toolkit UMD naming #15

Open rjimenezda opened 5 years ago

rjimenezda commented 5 years ago

The UMD module names are a bit of a mess right now. They are long, verbose, and not namespaced.

We should try to come up with a relatively short way of naming packages, maybe even namespacing?

IDEA: We could have different entry points for the UMDs, so they build a namespace. We shouldn't use carto. because I think VL and carto.js will not play nice.

VictorVelarde commented 4 years ago

At this point in time, I think we should go for a new namespace, starting from 'carto' root.

Something in the line of:

Opening the discussion with you @jesusbotella, @neokore and @elenatorro

rjimenezda commented 4 years ago

As long as it doesn't clash with VL and carto.js, which also live under 'carto'

VictorVelarde commented 4 years ago

or even if it does... 😄 (more to come soon...)

neokore commented 4 years ago

Taking carto as root is great, it makes easy to remember and sticks the library with the brand, but depending on how it will be distributed, we may need to add some "legacy users" checks. E.g. in case of reusing a CARTO package (let's say carto.js) and any user just upgrade it, it will be useful to detect legacy library calls (maybe the initialize methods) and throw an exception to alert that this library is not backwards compatible.

jesusbotella commented 4 years ago

I think we should use carto namespace no matter what. The library/module is not intended to work alongside CARTO-VL or CARTO.js, they have their own modules starting from carto namespace. So no need to be backwards compatible with our own libraries.

VictorVelarde commented 4 years ago

We'll make the move just after merging metrics-event PR #56 , starting a new base 'viz', isolated from the current -rc.013 line