Deploying a indavidual LWC ignores the .forceignore

[Brett Nelson]

Hello, Happy New Year!

‌

We have Typescript definition files in our LWCs and have added them to the .forceignore

# Typescript type definitions
src/**/@types/**
src/**/@types
src/**/*.ts 

When we run Deploy All Metadata on the module from IC2 everything deploys fine.

‌

When we run Deploy All Metadata on a single LWC that has type definition files in the folders the following error occurs.

Failures
========
- apps/operations/ui/home/c-ops-home/lwc/opsHome/@types/lightning-navigation.d.ts: ERROR at line 1, column 1 - Bad file:Content is not allowed in prolog.

‌

If I deploy the component with the SF CLI, it deploys fine.

brettcr git:(dev) sf project deploy start  --source-dir ./src/apps/operations/ui/home/c-ops-home/
Deploying v59.0 metadata to [e-mail] using the v59.0 SOAP API.
Deploy ID: 0Af7f00001DeG0bCAF
Status: Succeeded | ████████████████████████████████████████ | 1/1 Components | Tracking: 5/5

Deployed Source
=================================================================================================================
| State   Name    Type                     Path                                                                   
| ─────── ─────── ──────────────────────── ────────────────────────────────────────────────────────────────────── 
| Changed opsHome LightningComponentBundle src/apps/operations/ui/home/c-ops-home/lwc/opsHome/opsHome.css         
| Changed opsHome LightningComponentBundle src/apps/operations/ui/home/c-ops-home/lwc/opsHome/opsHome.html        
| Changed opsHome LightningComponentBundle src/apps/operations/ui/home/c-ops-home/lwc/opsHome/opsHome.js          
| Changed opsHome LightningComponentBundle src/apps/operations/ui/home/c-ops-home/lwc/opsHome/opsHome.js-meta.xml 

‌

‌

If the .forceigore could be respected for individual components deployments that would be nice.

‌

This was encountered with version 2.2.9.4 and 2.2.9.5

‌

Thanks,

Brett

[Scott Wells]

Thanks for reporting. Easily fixed. Basically in a source format project, IC2 tries to bypass the CLI for metadata types where source format and metadata format are identical, and the direct API-based deployer wasn't checking whether individual bundle files were ignored. I've added that as an additional filter for inclusion in the next build.

Your use case has me curious, though. Are those type definitions for LWC standard APIs? If so, are you finding that IC2 isn't providing proper definitions for those itself? It should be bundling solid type definitions for the standard APIs, well enough to provide a very strongly-typed LWC editor experience. If you're not finding that to be the case, please log another bug with clear examples of the things that don't work properly in the absence of your own type definitions so that I can resolve those for all other users.

[Scott Wells]

One other question for you about this project. Given the references to src/, is this a source format project or a metadata format project? Right now IC2 doesn’t apply .forceignore filtering on metadata format projects. That could obviously change, but it would be good to know if that’s something that people are expecting/needing to work.

[Scott Wells]

@Brett Nelson , I’ve implemented a fix for the original issue where individual bundle files aren’t being properly filtered by .forceignore. However, I have not enabled .forceignore filtering in metadata format projects. Can you confirm whether this issue is manifesting in a metadata format project or a source format project so I can understand whether such a change might be required as well to address the issue completely?

[Scott Wells]

Delivered in 2.2.9.6. Note that if .forceignore filtering is needed in metadata format projects, please open that as a separate enhancement request.