CED-1724: new folder structure and publish process for v3

[nathanielwarner]

🔗 Linked issue

https://energysage.atlassian.net/browse/CED-1724

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

• Removes all legacy stuff (es-design-system and es-vue-base)
  • Will be retained along with the old es-bs-base on a separate fork before merging the Vue 3 branch into main
• Renames es-bs-base to es-ds-styles and removes JavaScript stuff from it
• Sets up a publishing process for v3. Rather than using lerna or another solution, it's just managed through the makefile. npm publish is invoked for es-bs-base (using the alpha tag) and es-ds-components
  • Management of version numbers is therefore manual for the time being.
  • The new steps to publish is documented in the readme
• Switch to explicit imports of PrimeVue components to enable tree shaking
• Move the nuxt config from es-ds-docs to es-ds-components. Ditto for package json dependencies

🥼 Testing

Manually tested publish process

🧐 Feedback Requested / Focus Areas

• My update-docs-deps section of the makefile currently uninstalls and reinstalls es-ds-styles and es-ds-components in order to get the latest version. My attempts with using npm update were unsuccessful. Do you have any pointers here?

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.
• I have documented testing approach

[lgeggleston]

Your updates to make all the 2.0 processes legacy and to the package files make sense; README updates also look good! The updated Makefile commands make sense too I think, though I have limited experience with them so curious for Tom & Eric's thoughts when they're back.
General question, though looks like it works fine, what are the benefits/considerations to moving away from Lerna or a different monorepo manager?

[nathanielwarner]

curious for Tom & Eric's thoughts when they're back.

Agreed! No rush in any case.

what are the benefits/considerations to moving away from Lerna or a different monorepo manager?

For the time being, I didn't mess with lerna because I didn't want to break the legacy build and publishing which does rely on lerna. And to be honest, I'm also not sure what value lerna adds compared to just having the sequence of steps in the makefile. Maybe the automatic version increment comes from there? This is definitely something for Tom and Eric to weigh in on.

I mentioned it in the big PR as well, but it seems like it'd be easier to shed the legacy stuff in this branch. The old (v2) design system could be maintained on its own branch after merging v3.

[tomleo]

At a high-level my suggestion would be to keep commands like lint, test, and publish inclusive to all packages in this mono-repo.

Most of the time we'll mostly want to target newer projects, and so I'd suggest perhaps adding commands like X-next to target prime specific repos for faster linting and testing and building.

[tomleo]

A few things inline, also couldn't find good documentation around tsconfig's in mono-repos 🤔, but otherwise 👍