mady icon indicating copy to clipboard operation
mady copied to clipboard

Ability to repackage for production

Open sullivanpt opened this issue 7 years ago • 2 comments
trafficstars

Hello, forgive me for taking some liberties with your publishing structure. This change enables a second npm package that includes only the resources and dependencies needed for a production deployment to be published from this repository.

In this implementation, the original npm build and publish process is the same; however, after publishing mady, we can publish mady-production with the following

$ npm run build:production
$ cd production
$ npm version minor # or some other method to sync the package.json version number
$ npm publish

I've gone ahead and published the 2.11.1 release so I can consume it in my build pipeline. And I think I've given you publish access to npm as well.

I'll caveat this particular implementation is only one of many possible mechanisms we could use to publish a production mode dependency. The most straight-forward but intrusive of which would be to split the repo into several. I'm happy to rework this based on your feedback.

sullivanpt avatar Mar 19 '18 23:03 sullivanpt

Thanks for the proposal!

In fact, my mid-term plan is to reorganise mady into a monorepo using oao, with probably three parts:

  • mady: a wrapper, for backwards-compatibility (current applications depending just on mady would continue working)
  • mady-translator-tools: the translation application
  • mady-translate: the translate function (what you call mady-production)

I hope it won't take much time, but feel free to use mady-production for the time being!

guigrpa avatar Mar 21 '18 11:03 guigrpa

I was so going to use mady-translate, but I changed my mind at the last minute; last minute decisions are always a bad idea, LOL. My own bias is against yarn, but you oao mono repo tool is really cool. (aside: I feel yarn served its purpose in forcing npm to improve and now it's just unnecessarily fragmenting the community, like node.io). update: actually I prefer 'mady-localize' for this package, since it is used for the localization step

Adding 'translate' in the name should help with discoverability too. If I can make another suggestion, when you republish to npm can you add 'i18n' somewhere in the name? It was several weeks of convoluted searching before I stumbled unto this project. Started with 'i18n' named projects, then when those didn't wow me I searched for 'local', 'global', then stumbled on 'messageformat' (only because I was reading angular2 code), and then finally landed here..

As long as I'm throwing advice your way, it'd be great if you could split the translator-tools into two packages: a stand-alone set of file parsers and writers, and then the web app itself. I can envision a need to have a set of CLI based tools for extraction and modifying the translation DB that is independent of the file watching web app. update: I'm finding I really need the tools separate from the UI, for example I want to be able to run "mady --recompile" as part of my build process, which currently has no option to run without also launching the UI

Looking forward to the repackaging and the increased flexibility. I've got a lot plans for your library . Seriously, thanks for your hard work here!

sullivanpt avatar Mar 21 '18 16:03 sullivanpt