Repository navigation
What's the plan for plugin-template-sf's dependency on the now-archived @salesforce/dev-scripts? #3599
|
"devDependencies": {
"@salesforce/dev-scripts": "^11.0.4",
...
},
"scripts": {
"clean": "sf-clean",
"docs": "sf-docs",
"prepack": "sf-prepack",
"prepare": "sf-install",
...
}Since Curious what the team's thinking is here:
Happy to put together a PR against the template if there's an agreed direction. |
Replies: 2 comments
|
I'm a third-party plugin author myself and just to voice an opinion here based on the 6 or so Salesforce plugins I have in circulation. I have migrated off Salesforce's dev-scripts/etc. they provide with the CLI plugin template. I was inspired to do so by @scolladon who has done similar in sfdx-git-delta. The current sf plugin templates are still based on yarn, nyc, and mocha frameworks which are a bit outdated. I followed his lead with migration from yarn to npm, nyc/mocha to vitest (which provides easy to see test coverage of your plugin), and off their prettier/eslint configs to biomejs. I also have moved off their GitHub workflows and just maintain in-house versions due to their workflows depending on yarn commands. I know this is more effort, but perhaps we can create a 3rd party template that Salesforce community plugins users can keep up to date with the latest tech without depending on Salesforce's team. The core workflow of building, running tests (unit and non-unit), and publishing to NPM is pretty straight forward to just maintain directly with wireit. And there's only 3 core deps and 2 dev deps that is really needed from Salesforce for oclif support. I can help out if you're interested, but I know it's not as convenient as something Salesforce actively maintains. EDIT: See https://github.com/mcarvin8/3dx/ if you're interested in the same template I'm basically using in all of my plugins. |
|
Hi - |
Hi -
dev-scriptswas archived by one of our internal checks, we've unarchived it now