0

my team and I are trying to deploy an LWC (tried to both a scratch org & a dev org) using the following command:

sfdx force:source:deploy -p "force-app/main/default/lwc/internal/lwc/callbackIdRetriever"

However we have been getting the following error:

Type   Name      Problem
─────  ────────  ──────────────────────────────────────────────────────────────────────────────
Error  internal  No base file for markup://mynamespace:internal
Error  internal  duplicate value found: <unknown> duplicates value on record with id: <unknown>
Error  internal  duplicate value found: <unknown> duplicates value on record with id: <unknown>
Error  internal  duplicate value found: <unknown> duplicates value on record with id: <unknown>
Error  internal  duplicate value found: <unknown> duplicates value on record with id: <unknown>

I have checked the following are correct in our project as suggested from other posts but still no luck.

  • Component filenames are the same as the enclosing component folder just above it.

  • Component name is not the same name as the vs code project folder name.

  • name of LWC component starts with lowercase letter.

The only thing I've also noticed is our subfolders under the lwc directory. Deployment seems to work if component is directly under lwc (e.g. lwc/callbackIdRetriever instead of lwc/internal/lwc/callbackIdRetriever). Though these subfolders existed since the project was created and we were able to deploy before. These errors just started appearing about a week ago.

6
  • could it be that double lwc folder?
    – Damecek
    Sep 27 at 13:38
  • lwc/internal/lwc
    – Damecek
    Sep 27 at 13:38
  • @Damecek, tried renaming that second lwc folder to something different but still the same error.
    – ancrila
    Sep 27 at 13:43
  • I've never seen a project structure that introduces additional sub-folders like this other than for organizing ZIP-based static resources and for having additional files explicitly imported into LWCs. I'm surprised it was working before at all, unless "internal" is an LWC component and the "lwc/callbackIdRetriever" folder simply contains additional files imported into that LWC.
    – Phil W
    Sep 27 at 13:51
  • @PhilW internal/lwc are just subfolders to organise them within the main lwc folder.
    – ancrila
    Sep 27 at 14:03
1

The first lwc that is encountered in a directory is considered the containing directory for all LWC components. Since you named it /lwc/internal/lwc/callbackIdRetriever, the system thinks you're trying to declare a component called internal. All of the source in those directories will be collapsed into a single folder for deployment, which means that any "duplicate" file names would cause this error.

This is true for many of the special names that are used to detect what files are being deployed, such as aura, classes, objects, etc. For example, if you declare a directory as main/default/lwc/aura, and you try to put Aura components in aura, they will be parsed as LWC components and fail to deploy, and if you named your directories as main/default/aura/lwc, those files would be processed as Aura components, not LWCs. You need to be mindful of this limitation when creating your directory structures.

1

LWC, in particular, are quite restrictive in their structure. Salesforce DX Project Structure and Source Format

Lightning web components must reside in a directory named lwc under the directory.

Even with the above restriction, you could define multiple package directories to have different lwc folders, but you can't have subfolders within lwc.

{
    "packageDirectories": [
        { "path": "force-app/internal", "default": true },
        { "path": "force-app/fancyStuff", "default": false }
    ]
}

/force-app/internal/main/default/lwc/myInternalComponent
...
/force-app/fancyStuff/main/default/lwc/myFancyStuff

Deploying and retrieving with the above works assuming source control is your source of truth (which it should be). If someone were to retrieve all the metadata from the org in an empty, new local project - it won't split anything up.

2
  • 1
    Retrieving will work just fine; new components will end up in force-app/internal (it's the default), but existing sources will end up in force-app/fancyStuff if that's where they are located.
    – sfdcfox
    Sep 27 at 15:44
  • good catch - I meant for anyone else retrieving from the org with nothing in their local. Source control should be the source of truth so it shouldn't really happen. Sep 27 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.