- From: Lukas Oppermann via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Mar 2021 10:28:39 +0000
- To: public-design-tokens-log@w3.org
Hey @kaelig, > I believe it was related to the version of the file itself, not of the token spec. That sounds great. I think this is something that is definitely needed! Your "hunch" seems very likely to me. However in any of those cases I think it would be helpful to have some meta data and a version within the token payload. This way it does not matter if you get the token from a broker via an api request, pull it from an npm package or import a json file that the design team stores on a shared drive. Keeping a version tightly coupled with the tokens just makes sense. Like the version number that you have in a package.json. It makes the product (token.json) more resilient as it does not rely on a specific type of storage. It also means that caching the payload (tokens) will always keep the version as well, so it makes it easy to compare if something has changed and a cache needs to be invalidated. Let me know what your thoughts are on this. Just as a last thought, DSP has a `spec_version` in addition to the token version. I think this is a great idea if you think about the tooling, as this makes it easier to change specs later on without breaking tools (The issue that still hunts the internet 😉 ). -- GitHub Notification of comment by lukasoppermann Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/1#issuecomment-789609568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 March 2021 10:28:41 UTC