flores95 commented 5 years ago

Summary

Can't deploy class to sandbox using force:source:deploy

Steps To Reproduce:

Right click in source
Choose SFDX: Deploy This Source to Org

Expected result

Source is deployed to org.

Actual result

sfdx force:source:deploy --sourcepath r:\src\SFCI\src\classes\FeatureAccessHandler_Test.cls ERROR: The "path" argument must be of type string. Received type undefined. sfdx force:source:deploy --sourcepath r:\src\SFCI\src\classes\FeatureAccessHandler_Test.cls ended with exit code 1

VS Code Version: 1.28.2

SFDX CLI Version: sfdx-cli/6.38.0 (windows-x64) node-v11.1.0

OS and version: Windows 10

JorneVL commented 5 years ago

I have the same problem with the latest versions I add the full error {"message":"Path must be a string. Received undefined","status":1,"stack":"TypeError: Path must be a string. Received undefined\n at assertPath (path.js:28:11)\n at Object.join (path.js:499:7)\n at new SourceWorkspaceAdapter (C:\\Users\\<USERNAME>\\AppData\\Local\\sfdx\\client\\node_modules\\salesforce-alm\\dist\\lib\\sourceWorkspaceAdapter.js:52:31)\n at SourceDeployApi.<anonymous> (C:\\Users\\<USERNAME>\\AppData\\Local\\sfdx\\client\\node_modules\\salesforce-alm\\dist\\lib\\source\\sourceDeployApi.js:44:24)\n at Generator.next (<anonymous>)\n at fulfilled (C:\\Users\\<USERNAME>\\AppData\\Local\\sfdx\\client\\node_modules\\salesforce-alm\\dist\\lib\\source\\sourceDeployApi.js:10:58)\n at <anonymous>","name":"TypeError","warnings":["All --json output, including on error, is moving to stdout. Use the SFDX_JSON_TO_STDOUT environment variable to move over to the new functionality. This will become the default in version 45."]}

JimSuplizio commented 5 years ago

@flores95 and @JorneVL, I spent a chunk of yesterday trying to reproduce this and was unable to. We've had a number of CLI/VS Code updates. That being said I tested things against both scratch and sandbox as well as in VS Code and with the CLI directly. I was unable to reproduce the issue. Looking at commands and the output (there's a second one in the GIT link) there's nothing special about the directories, class names or even the manner in which the deploy is being done. The syntax for the deploy is also correct with what the CLI expects. If either of you are still seeing this issue please respond I'll re-open the item.

I tested on with the following CLI, OS, VS Code and Salesforce extension version. SFDX CLI version sfdx-cli/6.55.1-be0b3dc4c4 (windows-x64) node-v8.9.4

OS/Version Microsoft Windows [Version 10.0.16299.967] Linux Ubuntu 14.04

VS Code Version Version: 1.31.1 (user setup) Commit: 1b8e8302e405050205e69b59abb3559592bb9e60 Date: 2019-02-12T02:20:54.427Z Electron: 3.1.2 Chrome: 66.0.3359.181 Node.js: 10.2.0 V8: 6.6.346.32 OS: Windows_NT x64 10.0.16299

Salesforce Extension Version 43.5.0

yjanezou commented 5 years ago

@JimSuplizio I am getting same error on my mac OS when trying to push files:

sfdx force:source:push

ERROR running force:source:push: The "path" argument must be of type string. Received type undefined

rmsjts88 commented 5 years ago

Nice, ... can't reproduce so the issue is closed!! Well I have this same stinking problem with your code. I guess I have to fix it myself. All force:source commands pull push and status fail, could be others. I have two different force-app project. the force:source commands work in one but not the other. The only place I see "Path" used is in the sfdx-projecct.json which has a location of the folder by name where commands are run against.

ntotten commented 5 years ago

@rmsjts88 I understand you are frustrated, but I am not sure what you expect us to do. If you can provide detailed reproduction steps and a sample repository we are happy to look into this, but we can't fix a bug we can't find.

I would suggest you: 1) Create a project that you causes the issue and push it to a git repo 2) Provide EXACT steps for how the issues occurs 3) Provide detailed information about what OS you are using, what version of VS Code, what version of the CLI, and what version of the Salesforce Extensions you are running. Additionally, what other extensions in VS Code are you running.

If you can provide us with that information it would help us track down the root cause. As of now, we have been unable to reproduce this.

joshua-nicholson commented 5 years ago

@ntotten and @JimSuplizio, I am having this same issue attempting to do force:source:retrieve using the command sfdx force:source:retrieve --manifest assets/package.xml --targetusername DevHub --wait 10 --loglevel debug. I encountered this when working through the 'Create a Salesforce DX Project' module of the 'Develop an App with Salesforce CLI and Source Control' trail.

I am also on Mac OSX which seems to be a common thread, High Sierra 10.13.6. Using the latest version of the CLI, 7.5.0-e6ca93eee8.

After enabling debug and looking at the logs, the more detailed error I get is

"[ '\\u001b[1mERROR running force:source:retrieve: \\u001b[22m',\n '\\u001b[31mThe \"path\" argument must be of type string. Received type undefined\\u001b[39m' ]"

Here is the log file if you want to look at the rest of it. I hope this helps provide some clarification on what others are experiencing, let me know if you need me to go through any other troubleshooting steps.

Edit: I have uploaded my current project I'm experiencing this issue in to GitHub here

userAyaan commented 5 years ago

@joshua-nicholson @ntotten @JimSuplizio @JorneVL @flores95 In your sfdx-project.json add this entry

"packageDirectories": [{ "path": "force-app", "default": true }] This resolved my problem. if you are not using force-app as the directory ( such as src) use the path of that directory.

rendall commented 5 years ago

Can confirm this bug still persists.

> sfdx force:source:push
ERROR running force:source:push:  The "path" argument must be of type string. Received type undefined

My sfdx-project.json file is

{
    "namespace": "",
    "packageDirectories": [
        {
            "path": "src",
            "default": true
        }
    ],
    "sfdcLoginUrl": "https://astonishing-giraffe-42xkcd.my.salesforce.com/", //not actually this url
    "sourceApiVersion": "44.0"
}

I suggest to admins not closing this, but leave it open with a more information tag. Closed implies that it's fixed or a no-fix. Leaving it open allows users who encounter this problem to find it more easily and perhaps add information that you will find helpful.

rendall commented 5 years ago

Running the command with the --json flag yields a bit more information. Perhaps the devs would consider adding a helpful error about what file or resource is throwing the error.

{
    "status": 1,
    "name": "TypeError [ERR_INVALID_ARG_TYPE]",
    "message": "The \"path\" argument must be of type string. Received type undefined",
    "exitCode": 1,
    "commandName": "SourcePushCommand",
    "stack": "TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received type undefined\n    at validateString (internal/validators.js:125:11)\n    at Object.resolve (path.js:161:7)\n    at Proxy.copy (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\fs-extra\\lib\\copy\\copy.js:27:28)\n    at Proxy.copy (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\universalify\\index.js:5:67)\n    at Proxy.tryCatcher (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\util.js:16:23)\n    at Proxy.ret (eval at makeNodePromisifiedEval (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\promisify.js:184:12), <anonymous>:15:23)\n    at BBPromise.resolve.then.sourcePath (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\dist\\lib\\source\\sourceConvertApi.js:155:44)\n    at tryCatcher (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\util.js:16:23)\n    at Promise._settlePromiseFromHandler (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\promise.js:510:31)\n    at Promise._settlePromise (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\promise.js:567:18)\n    at Promise._settlePromiseCtx (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\promise.js:604:10)\n    at Async._drainQueue (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\async.js:143:12)\n    at Async._drainQueues (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\async.js:148:10)\n    at Immediate.Async.drainQueues [as _onImmediate] (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\bluebird\\js\\release\\async.js:17:14)\n    at runCallback (timers.js:705:18)\n    at tryOnImmediate (timers.js:676:5)\nOuter stack:\n    at Function.wrap (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\@salesforce\\core\\lib\\sfdxError.js:151:27)\n    at SourcePushCommand.catch (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\dist\\ToolbeltCommand.js:216:46)",
    "warnings": []
}

rendall commented 5 years ago

After further investigation, I was able to track the error in my case to a missing resource file. There was a some-resource-meta.xml file but no corresponding some-resource file.

Interesting, because this identical situation sometimes, inconsistently, throws another error:

> sfdx force:source:push
ERROR running force:source:push:  ENOENT: no such file or directory, scandir '...\project-dir\src\staticresources\some-resource'

I suggest the fix for this bug is ensuring that the error message for missing resource files is more consistent.

rendall commented 5 years ago

@JimSuplizio There have been some developments, here. We very likely solved this.

ntotten commented 5 years ago

@rendall Thanks for the updates. This does indeed look like a bug on the CLI. I reopened the issue and moved it to the CLI repo.

Rasmus-Josefsen commented 5 years ago

I am experiencing the same issue following the Lightning Web Components basic trailhead module. - I am in the section 'Push and Deploy lightning Web Component Files' and after adding the files for bikeCard when I try to push to the org I get the error: ERROR running force:source:push: The "path" argument must be of type string. Received type undefined

rendall commented 5 years ago

@Rasmus-Josefsen try looking through your static resources. See https://github.com/forcedotcom/cli/issues/94#issuecomment-495123248

steals commented 5 years ago

I've just had the exact same error with the latest cli (7.8.1) The "path" argument must be of type string. Received type undefined that was caused by missing static resource folder (I've cleaned it up but forgot to delete the corresponding meta.xml file)

Rasmus-Josefsen commented 5 years ago

@rendall In my static resources I have a folder named bike_assets and a file bike_assets.resource-meta.xml

This is the contents of the XML file: <?xml version="1.0" encoding="UTF-8"?>

Private application/zip

I am just starting out, so if you could please spell out it out for me how to move forward. Thank you.

rendall commented 5 years ago

I'm not an expert either, but I think bike_assets should not be a folder, but a file. If it's a folder, something is wrong and that might be the cause of your error.

Rasmus-Josefsen commented 5 years ago

Thank for the advice Rendall. I ended up solving it by reinstalling the repository and then I figured out that I had earlier not placed the files in the correct folder (bikeCard) which might have been what caused the issue.

dcarroll commented 5 years ago

I have seen this before and it is weird. In my case, there was a .yo-rc.json file upstream in the path to my project and some dependent lib would look up the path and discover it and then the command would fail. The fact that the stack trace has "at Generator.next" hints and some yeoman generator code being invoked.

clairebianchi commented 5 years ago

@dcarroll Can you give us the steps you took to see the error originally? @Rasmus-Josefsen sounds like you have gotten past the error, if not can you please try Dave's suggestion above?

aitiancai commented 5 years ago

ERROR running force:source:retrieve: The "path" argument must be of type string. Received type undefined 18:15:46.996 sfdx force:source:retrieve --manifest c:\soft\VSCode\poject\XinAn\manifest\package.xml ended with exit code 1

aitiancai commented 5 years ago

I've just had the exact same error with the latest cli (7.8.1)

bdJohnson72 commented 5 years ago

I am experiencing the same thing. I am working on the Trailhead module Develop an App With CLI and Source Control. When I try to pull source I get the following.

sfdx force:source:retrieve --manifest assets/package.xml --targetusername pdii --wait 10 ERROR running force:source:retrieve: A default package path string is required for SourceWorkspaceAdapter.

The JSON flag give the following info

"status": 1, "name": "missing_package_path", "message": "A default package path string is required for SourceWorkspaceAdapter.", "exitCode": 1, "commandName": "SourceRetrieveCommand", "stack": "missing_package_path: A default package path string is required for SourceWorkspaceAdapter.\n at Function.create (C:\Users\Admin\AppData\Local\sfdx\client\7.15.3-c7d407d236\node_modules\salesforce-alm\node_modules\@salesforce\core\lib\sfdxError.js:141:16)\n at new SourceWorkspaceAdapter (C:\Users\Admin\AppData\Local\sfdx\client\7.15.3-c7d407d236\node_modules\salesforce-alm\dist\lib\source\sourceWorkspaceAdapter.js:75:36)\n at Function.create (C:\Users\Admin\AppData\Local\sfdx\client\7.15.3-c7d407d236\node_modules\salesforce-alm\node_modules\@salesforce\kit\lib\creatable.js:26:26)\n at SourceRetrieve.retrieve (C:\Users\Admin\AppData\Local\sfdx\client\7.15.3-c7d407d236\node_modules\salesforce-alm\dist\lib\source\sourceRetrieve.js:45:74)", "warnings": [] }

tnoonan-salesforce commented 5 years ago

@bdJohnson72 Can you re-reun the problem command and add DEBUG=sfdx:SourceWorkspaceAdapter

Like This:

DEBUG=sfdx:SourceWorkspaceAdapter sfdx force:source:retrieve --manifest assets/package.xml --targetusername pdii --wait 10

Also, what does your sfdx-project.json look like?

patmcclellan commented 5 years ago

I'm now getting this error. This happened just after merging a branch back to master, then switching VS Code over to Master. Entirely possible that it mucked up some of the config files...

sfdx-cli: Updating CLI... already on latest version: 7.19.0-c5be43915c

Here's my sfdx-project.json: { "packageDirectories": [ { "path": "force-app", "default": true } ], "namespace": "", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "46.0" }

Here's the push --json output: "status": 1, "name": "TypeError [ERR_INVALID_ARG_TYPE]", "message": "The \"path\" argument must be of type string. Received type undefined", "exitCode": 1, "commandName": "SourcePushCommand", "stack": "TypeError [ERR_INVALID_ARG_TYPE]: The \"path\" argument must be of type string. Received type undefined at validateString (internal/validators.js:125:11) at Object.resolve (path.js:1080:7) at Proxy.copy (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/salesforce-alm/node_modules/fs-extra/lib/copy/copy.js:27:28) at Proxy.copy (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/universalify/index.js:5:67) at Proxy.tryCatcher (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/util.js:16:23) at Proxy.ret (eval at makeNodePromisifiedEval (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:15:23) at BBPromise.resolve.then.sourcePath (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/salesforce-alm/dist/lib/source/sourceConvertApi.js:164:44) at tryCatcher (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/promise.js:517:31) at Promise._settlePromise (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/promise.js:574:18) at Promise._settlePromiseCtx (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/promise.js:611:10) at _drainQueueStep (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/async.js:142:12) at _drainQueue (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/async.js:131:9) at Async._drainQueues (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/async.js:147:5) at Immediate.Async.drainQueues [as _onImmediate] (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/bluebird/js/release/async.js:17:14) at runCallback (timers.js:705:18) Outer stack: at Function.wrap (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/@salesforce/core/lib/sfdxError.js:151:27) at SourcePushCommand.catch (/Users/patmcclellan/.local/share/sfdx/client/7.19.0-c5be43915c/node_modules/salesforce-alm/dist/ToolbeltCommand.js:230:46)", "warnings": []

@dcarroll @ntotten

patmcclellan commented 5 years ago

This has me dead in the water. I can't push or deploy source, I can't convert source to metadata.

What's especially frustrating is that I don't know what's going on behind the scenes, so I don't know how to attempt to debug it. Looking back through the thread, and based on the fact that I just switched branches, I suspect I've got some random file that's missing or out of place, but I don't know how to begin to check that.

The error says the "path" parameter is not of type string. There's only one place I'm aware of that has that "path" parameter (in the sfdx-project.json), and clearly that value is a String. So I suspect that error message is inaccurate -- meaning it's not helping track down the real issue.

Or... I'm wondering if the path argument in question is something in a Node module. I know nothing about Node, but at ./node_modules/path-parse/index.js, there are a couple of functions that seem to be checking the validity of a path parameter, and they have error messages similar to the error we're getting. I did a search of "argument must be of type" in **/node_modules but got nothing. So, I'm now thinking the error is generated elsewhere.

The error also shows up in the Problems window (see image), but when i try to click it to navigate to the offending file, it says Unable to open '': File is a directory.

I welcome any suggestions on steps I can take to move forward... Screen Shot 2019-08-08 at 4 54 28 PM

clairebianchi commented 5 years ago

@patmcclellan we are looking into your issue now. I'll circle back with updates and if we need anything else from you

kcappieg commented 5 years ago

Edited

I'm having this issue too. I narrowed it down to only times when I'm trying to deploy a flexipage. Doesn't seem to matter what kind of flexipage or what the content is.

My directory structure is:

root
- codebase
- package-name
  - feature-name
  - flexipages
    - XXX.flexipage-meta.xml

('package-name' and 'feature-name' are generic to my example).

running:

sfdx force:source:deploy -p codebase/package-name

Result:

ERROR running force:source:deploy: The "path" argument must be of type string. Received type undefined

sfdx --version
sfdx-cli/7.14.0-bd96f098e0 win32-x64 node-v10.15.3

Hopefully that helps. Please let me know!

Update

I just updated the sfdx cli from the website and got a different error:

sfdx force:source:deploy -p codebase/package-name/ --json
{
    "status": 1,
    "name": "TypeError",
    "message": "Cannot read property 'create' of undefined",
    "exitCode": 1,
    "commandName": "SourceDeployCommand",
    "stack": "TypeError: Cannot read property 'create' of undefined\n    at SourceDeployCommand.init (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\@salesforce\\command\\lib\\sfdxCommand.js:240:63)\nOuter stack:\n    at Function.wrap (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\node_modules\\@salesforce\\core\\lib\\sfdxError.js:153:27)\n    at SourceDeployCommand.catch (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\salesforce-alm\\dist\\ToolbeltCommand.js:216:46)\nOuter stack:\n    at Function.wrap (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\@salesforce\\command\\node_modules\\@salesforce\\core\\dist\\lib\\sfdxError.js:154:27)\n    at SourceDeployCommand.catch (C:\\Program Files\\Salesforce CLI\\client\\node_modules\\@salesforce\\command\\lib\\sfdxCommand.js:269:80)",
    "warnings": []
}

patmcclellan commented 5 years ago

@kcappieg Thanks for the info. I checked my .forceignore file and i have **flexipages in the ignore list, so that's not it for me. That idea got me checking other things, so I've tried ignoring lots of things, including:

**objectTranslations
**profiles
**flows
**flowDefinitions
**config
**queues
**tabs
**layouts
**flexipages

Still get the same error.

Since this started happening after I had done a big git merge, I started looking for any errant remnants of the merge conflict resolution... searching for things like <<<<< HEAD or >>>>> branch, but I can't find any places where the conflict didn't get resolved as it should. I'm still thinking that maybe there's some bit of text (like a quotation mark) in some file (maybe even in files I don't control, like in node_modules) that is preventing something from compiling or screwing up what is perceived to be a string.

patmcclellan commented 5 years ago

I found this post on Stack Exchange related to the same error message. He says he fixed it by correcting some corrupted code in the sourcePathInfos.json file for his scratch org.

I looked at that file for my situation, and that file is nearly 31k lines long, with a file path string repeated twice literally every 20 lines. They all look intact, and thanks to color coding in VS Code, I can affirm that they're all strings -- though I can't actually verify each of the 3,100 lines that are a file path. Trying to think of a way to grep that...

I renamed that file (rather than deleting it) and VS Code immediately alerted me that it couldn't find sourcePathInfos.json, and offered to create it. So I let it create a new one (figuring that's the best way to assure an uncorrupted file). Boom, just like that, it created a fresh version. Tried pushing, same error.

patmcclellan commented 5 years ago

FIXED IT! @clairebianchi I found that I could do a sfdx force:source:deploy -p _filepath_ on individual files and on directories. So, I started at the top and worked my way down.

sfdx force:source:deploy -p force-app/main/default = same error sfdx force:source:deploy -p force-app/main/default/applications = success sfdx force:source:deploy -p force-app/main/default/appMenus = success sfdx force:source:deploy -p force-app/main/default/aura = success sfdx force:source:deploy -p force-app/main/default/classes = success

...etc., until sfdx force:source:deploy -p force-app/main/default/staticResources = SAME ERROR

So I stepped into that directory and discovered a meta file for a graphic (png) that was missing. I pulled the png from my other files (not in the project), added it to the directory, then did...

sfdx force:source:deploy -p force-app/main/default/staticresources = SUCCESS

So then, I tried sfdx force:source:push and SUCCESS!

WHAT HAVE WE LEARNED?

That error message is not at all helpful, and appears to occur when there's a variety of errors in the package you're trying to push.
If you can still use deploy (I could), start at the top and work your way down until you can isolate the directory/file where the error originates.

kcappieg commented 5 years ago

@patmcclellan Unfortunately that doesn't help my problem very much. As far as I can tell the flexipages are formatted correctly.

It's not strictly required that I have to source-track them, but without them that means my packages that track objects can't specify a default View override, meaning I have to make sure a particular page is the default for all relevant apps. Not the end of the world, but still very annoying.

So if anyone has a solution for flexipages not being deployable via force:source:deploy, I'd love to hear it!

patmcclellan commented 5 years ago

@kcappieg Based on this error and what I've learned, I suspect there's something corrupted in one of the files, rather than a general issue with deploying flexipages. Try this... go through your flexipages one by one and see if it'll deploy. Use the file path, like this:

sfdx force:source:deploy -p codebase/package-name/feature-name/flexipages/[whatever].flexipage-meta.xml

See which ones cause the error.

kcappieg commented 5 years ago

Well, that was insidious...

It was not any one flexipage, but rather the fact that the feature directory was named "documents". I have a feature that involves storing documents in a cloud storage location. It was only debugging SFDX CLI code that I found that for some reason flexipages were getting mistaken as Document metadata types.

So I agree with @patmcclellan 's conclusion: we need better error messages!

rvwatch commented 5 years ago

Finally managed to get a repro on this one via static resources. Thanks, @patmcclellan & @rendall ! I'm going to dig into this one a bit more and see if I can get the error message updated. The missing meta.xml file appears to generate a proper message but not so much vice-versa. It's tricky as apparently this only happens with certain types. Should have an update for this one fairly soon.

rvwatch commented 5 years ago

Steps To Reproduce:

Create a scratch org from an existing or new sfdx project.
Create a new static resource from the UI of the new scratch org. (sfdx force:org:open)
Run sfdx force:source:pull
In your local project files, delete the static resource file itself but leave the generated meta.xml reference for that file in place.
Create a new scratch org
run sfdx force:source:push to the new scratch org
Angrily stare at the vague error message.

patmcclellan commented 5 years ago

That will exactly reproduce my issue, however, I suspect this vague error message may apply more broadly... perhaps whenever there's a meta-file without a matching source file? And then, also, when there's something actually wrong with the path (but the error message should be more prescriptive on WHERE that path parameter is bad).

rvwatch commented 5 years ago

Interestingly, I tried this with several different types and usually received much more helpful error messages. Trigger types, for example, generated a useful message. It wasn't until we used a static resource that it finally reared its ugly head.

erocheleau commented 5 years ago

Hopefully this may be useful to someone:

I had the same or a very similar issue: ERROR running force:source:push: The "path" argument must be of type string. Received type object

I checked on another stackexchange question : https://salesforce.stackexchange.com/questions/251815/sfdx-error-path-must-be-a-string-received-null And the response mentionned checking if any of the path had been corrupted in the .sfdx/{scratch-username}/ folder of your project. Turns out for some reason, I had no sourcePathInfos.json file only a .sourcePathInfos.json.bak.

Apparently, as some of other problems with sfdx sometimes just deleting that .sfdx/{scratch-username}/ folder fixes the issues. That's exactly what I did, and I no longer have an issue re-pushing everything after that.

(It repushes everything since it no longer has any "sync" data on files., so do this only if your local repo is your source of truth for files).

jakubmplatek commented 5 years ago

Hi All, Nice little community you've got going here!

Just here to report that I had the same error message when after reorganising my source directories, I placed an object directory into a custom sub-directory of my package directory.

Changing the sub-directory name resolved the issue. example: before: force-app/schema/settings/CustomSettingc/ after: force-app/schema/objects/CustomSettingc/

I'm using custom path names for my classes all over the place, so I assumed I can do the same with objects - I was wrong.

Edit: to clarify, it's not just "setting" directory name that caused the error, so it's not caused by a reserved name - I tried with very custom names and it still threw the same error.

opensourcejunkie commented 4 years ago

@jakubmplatek Dude, you're awesome. I've been trying all the various fixes in this thread and around the internet, and your final comment's exactly what I needed. Thanks :-)

For anyone else who used a custom subdirectory, note that as a final step, I had to also delete my .sfdx/orgs/{scratch-org-name} directory before push would go through; it was probably caching the invalid path as described by others.

I agree with everyone else, more sensible error messages are a must.

carolinecanto commented 4 years ago

thanks @userAyaan, it worked!

Szandor72 commented 4 years ago

Yes, after re-ogranising my files, this happened. deleting .sfdx did not do the tick yet, nor undoing all my changes. now re-creating scratch org.

I could re-create the issue by:

moving main/default/object/Account to main/Accounts/
moving the folder back, solved the issue

vscuorzo commented 4 years ago

I ran into this issue today but for a different reason than everybody else. Apparently you'll get this kind of error if you add a lightning web component bundle to your source directory but don't put it in a proper location. In my case, I had the various files for the component in the lwc folder in a directory specific to the feature I was working on. To fix the problem, I had to create a folder beneath the lwc folder to contain those files.

In the end, it was user error on my part by not putting the files in the right place but this error message was extremely unhelpful so it took a long time to figure this out. It'd be nice if the CLI was able to at least tell me something about what tripped it up such as a parent directory where it died so my troubleshooting could have been more targeted.

ShredDentures commented 3 years ago

TypeError: The "path" argument must be of type string. Received null appears to be a Nodejs error. I don't think this is a bug, per se, in that there are multiple ways to throw this exception. Two things to check early in the problem solving process are first the Java.Home setting(s) and then to look for orphaned _meta.xml files. If the extension developers had created a custom error for at least the orphaned _meta.xml case mentioned, it would have saved me personally around 5 hours. Until that happens, the process of elimination suggested above by Github user patmcclellan is probably the fastest way to check for problems in source directories (also on StackExchange).