feat: Need to be able to impose our own file naming scheme to output bundles. p-<hash>.js alone does not satisfy

[celsoaguiar]

Prerequisites

• [X] I have read the Contributing Guidelines.
• [X] I agree to follow the Code of Conduct.
• [X] I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

We need to be able to impose our own file naming scheme to output bundles. p-.js alone does not satisfy. We'd rather have file names describing items like: "<org>-<project name>-<version>-<hash>-<component name>.js".

Describe the Use Case

We have a DLS library of web components to be used enterprise wide in our company. The compiled web components will be deployed to a CDN, and we want to be able to track down the file origin, build#, etc. We'd rather have file names describing items like: "<org>-<project name>-<version>-<hash>-<component name>.js". Because this feature is currently lacking, we are looking at setting up a folder structure within the CDN container, like org/project name/version/, which is far from ideal.

Describe Preferred Solution

Maybe a stencil.config parameter which takes a function would be ideal. This client supplied function would then provide a way to construct the file name.

Describe Alternatives

No response

Related Code

No response

Additional Information

No response

[rwaskiewicz]

Hey @celsoaguiar 👋

Thanks for detailed summary - I'd like to ask a few questions to try to understand your pain points a little better.

we are looking at setting up a folder structure within the CDN container, like org/project name/version/, which is far from ideal.

Can you explain why this isn't ideal to me for your use case? I'd like to understand the nuances of a directory/hierarchy-based approach vs designating these fields on the file itself. Thanks!

[celsoaguiar]

Can you explain why this isn't ideal to me for your use case? I'd like to understand the nuances of a directory/hierarchy-based approach vs designating these fields on the file itself. Thanks!

Hi @rwaskiewicz, thanks for the response, and sorry for the late reply. In most real life enterprise situations, typically, a dev will get just a file and will certainly not have access to the CDN folders when trying to fix a production bug. If you can pack the file origin information in its name it's a huge win for everyone. The dev will quickly understand where is the source of the issue, may help even triage bugs and give them the right destination. If you don't have any of those, the process to fix issues becomes way more difficult. Of course, any attempted solution would default to the existing file naming scheme so not to disrupt workflows already relying on that.