-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Custom Views Javascript template #3295
Conversation
🦋 Changeset detectedLatest commit: 30f01ac The changes in this PR will be included in the next version bump. This PR includes changesets to release 38 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@emmenko do you think we can already remove the experimental flag for creating Custom Views templates or should we keep it until the General Available stage? const throwIfApplicationTypeIsNotSupported = (
applicationType: TApplicationType
) => {
switch (applicationType) {
case applicationTypes['custom-view']: {
if (process.env.ENABLE_EXPERIMENTAL_CUSTOM_VIEWS !== 'true') {
throw new Error(`Custom Views generation is not yet supported.`);
}
break;
}
case applicationTypes['custom-application']:
break;
default: {
const applicationTypesList = Object.keys(applicationTypes).toString();
throw new Error(
`The provided application type "${applicationType}" does not exist. Available types are "${applicationTypesList}". Make sure you are also using the latest version of "@commercetools-frontend/create-mc-app".`
);
}
}
}; |
Deploy preview for merchant-center-application-kit ready! ✅ Preview Built with commit 30f01ac. |
Deploy preview for application-kit-custom-views ready! ✅ Preview Built with commit 30f01ac. |
@emmenko I also noticed we're testing Custom Applications template in CI but we're not doing it for Custom Views. Should I update the configuration to enable it? |
Yes please, that was a leftover I think |
I think we can keep it until general availability considering that the docs won't be "publicly" visible yet and that the configuration UI is also enabled for early adopters. |
Sorry I didn't give all the context in my first question. I was thinking that now we will be having users starting to develop Custom Views, it would be easier for them if we don't ask them to set the env var. If we keep the experimental flag, we need to also update the (private) docs to include over there the env variable consumers need to set in order for the Would it be ok to just update the example command? shell> ENABLE_EXPERIMENTAL_CUSTOM_VIEWS="true" npx @commercetools-frontend/create-mc-app@latest \
my-new-custom-view-project \
--application-type custom-view \
--template starter |
Good point. Ok then if you think it would be better we can remove the flag. If people ask and require access to Custom Views we can say it's in private beta and add them if they want to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome job! 🙌
Great idea with the composite action to simplify the setup and to have a consistent commands 🎉
.github/workflows/main.yml
Outdated
run: pnpm template-starter-typescript:build | ||
env: | ||
CTP_INITIAL_PROJECT_KEY: ${{ secrets.CYPRESS_PROJECT_KEY }} | ||
# TODO: Uncomment when we have Custom View e2e tests implemented |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can keep the step active and define a dummy command
"test:e2e:template-starter-custom-view": "echo \"No tests implemented yet\""
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated here: adc437d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I didn't understand the suggestion the first time I read it.
I updated after our meeting in this commit: b89ac73
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this file is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed here: 1b69e24
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also not needed.
Did you copy the Custom Application JS template or the Custom View TS template (and removed the types)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed here: 1b69e24
I copied the Custom Application JS template.
package.json
Outdated
"template-custom-view-starter-javascript:build": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run build", | ||
"template-custom-view-starter-javascript:start": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start", | ||
"template-custom-view-starter-javascript:start:prod:local": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start:prod:local", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: names seem to be a bit inconsistent with the Custom Applications
"template-custom-view-starter-javascript:build": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run build", | |
"template-custom-view-starter-javascript:start": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start", | |
"template-custom-view-starter-javascript:start:prod:local": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start:prod:local", | |
"template-custom-view-starter:build": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run build", | |
"template-custom-view-starter:start": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start", | |
"template-custom-view-starter:start:prod:local": "pnpm --filter @commercetools-applications/merchant-center-custom-view-template-starter run start:prod:local", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree they are inconsistent right now as I didn't want to change anything related to Custom Applications just in case there were any unexpected impact.
From my point of view, Custom Application commands are the ones who lack a more meaningful name and what I think it would have more sense is something like this:
"template-custom-application-starter-javascript:build"
"template-custom-application-starter-javascript:start"
"template-custom-application-starter-javascript:start:prod:local"
"template-custom-application-starter-typescript:build"
"template-custom-application-starter-typescript:start"
"template-custom-application-starter-typescript:start:prod:local"
"template-custom-view-starter-javascript:build"
"template-custom-view-starter-javascript:start"
"template-custom-view-starter-javascript:start:prod:local"
"template-custom-view-starter-typescript:build"
"template-custom-view-starter-typescript:start"
"template-custom-view-starter-typescript:start:prod:local"
Does it make sense to you our do you prefer to infer javascript is the default implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks for the clarification.
From my experience using other tools and libraries, JS is normally the default implementation yes. However, I do see your point and I don't mind either way. For me it's more important to have it consistent.
Maybe you can run a quick poll in the team to get their feedback as well. Renaming the Custom Applications template then should be a follow up.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated to default names to Javascript here: adc437d
"template-custom-application-starter:build"
"template-custom-application-starter:start"
"template-custom-application-starter:start:prod:local"
"template-custom-application-starter-typescript:build"
"template-custom-application-starter-typescript:start"
"template-custom-application-starter-typescript:start:prod:local"
"template-custom-view-starter:build"
"template-custom-view-starter:start"
"template-custom-view-starter:start:prod:local"
"template-custom-view-starter-typescript:build"
"template-custom-view-starter-typescript:start"
"template-custom-view-starter-typescript:start:prod:local"
console.log('==> Assert application config file exists'); | ||
if (applicationType === 'custom-application') { | ||
assert.strictEqual( | ||
doesFileExist(path.join(applicationPath, 'custom-application-config.mjs')), | ||
true | ||
); | ||
} else if (applicationType === 'custom-view') { | ||
assert.strictEqual( | ||
doesFileExist(path.join(applicationPath, 'custom-view-config.mjs')), | ||
true | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
doesFileExist(path.join(applicationPath, 'custom-application-config.mjs')), | ||
true | ||
); | ||
} else if (applicationType === 'custom-view') { | ||
assert.strictEqual( | ||
doesFileExist(path.join(applicationPath, 'custom-view-config.mjs')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: we can simply use existsSync
(we use it many places in the repo), so there is no need to have a try/catch
doesFileExist(path.join(applicationPath, 'custom-application-config.mjs')), | |
true | |
); | |
} else if (applicationType === 'custom-view') { | |
assert.strictEqual( | |
doesFileExist(path.join(applicationPath, 'custom-view-config.mjs')), | |
fs.existsSync(path.join(applicationPath, 'custom-application-config.mjs')), | |
true | |
); | |
} else if (applicationType === 'custom-view') { | |
assert.strictEqual( | |
fs.existsSync(path.join(applicationPath, 'custom-view-config.mjs')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used this implementation as it's the one recommended in Nodejs docs since fs.exists
is a deprecated function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦♂️ My bad, sorry.
I guess we would need to refactor the other places then to stop using fs.existsSync
.
I'll create a task.
# - name: Checkout | ||
# uses: actions/checkout@v4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this can be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed here: adc437d
|
||
inputs: | ||
template-name: | ||
description: 'Name of the template to test' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this is currently used as e.g. template-starter-typescript
or template-custom-view-starter-typescript
When I think about the create-mc-app
CLI options, the --template
option is either starter
or starter-template
.
I'm wondering if maybe we could have a similar properties here like application-type
and template-name
.
Example usage:
- name: Test Custom Application typescript starter template
uses: ./.github/actions/test-template-action
with:
application-type: custom-application
template-name: starter-typescript
With these two properties, we can then build the command names or whatever we need to. The main benefit I see with this is naming consistency and familiarity.
Just a suggestion anyway, happy to hear your thoughts 🤗
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree it's easier to understand.
Updated here: adc437d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work, thanks again 🙌 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: do we need a changeset for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added here: d63c893
Summary
New Custom Views Javascript template
Description
So far we only had a
Typescript
version of the template to bootstrap a new Custom View project.We're adding a new Javascript based template.