Asked  7 Months ago    Answers:  5   Viewed   40 times

I use psr-4 autoloader from composer:

"autoload": {
    "psr-4": {
        "DG\Munchkin\": "src/DG/Munch/"
    }
}

This loads classes from /var/www/html/xxx/vendor/yyy/src/DG/Munch

But how can I load classes from /var/www/html/xxx/?

I wrote my own autoloader, but when I require vendor/autoload.php (composer autoload) and my autoloader, it won't work until I create instance of a class in my own autoloader.

 Answers

75

The src directory would be in your project root. Its on the same level as vendor directory is.

If you define

"autoload": {
    "psr-4": {
        "DG\Munchkin\": "src/DG/Munch/"
    }
}

this will not load classes from /var/www/html/xxx/vendor/yyy/src/DG/Munch, like you stated.

Because your project structure is:

/var/www/html/
 +- /xxx (project)
     - composer.json
     +- /src
        +- DG
           +- Munch
     +- /vendor
        - autoload.php
        +- vendor-projectA
        +- vendor-projectB
        +- yyy

The DGMunchkin namespace would map to classes inside

/var/www/html/xxx/src/DG/Munch and not inside

/var/www/html/xxx/vendor/yyy/src/DG/Munch.

But how can I load classes from /var/www/html/xxx/?

Define the paths in the composer.json (inside /var/www/html/xxx/) of your project:

"autoload": {
    "psr-4": {
        "ProjectRoot\" : "", 
        "NamspaceInSourceDir\" : "src/"         
    }
 }

or load the composer autoloader in your index.php or during it's bootstrap and add the paths manually:

$loader = require 'vendor/autoload.php';
$loader->add('Namespace\Somewhere\Else\', __DIR__);
$loader->add('Namespace\Somewhere\Else2\', '/var/www/html/xxx');

Referencing: https://getcomposer.org/doc/04-schema.md#autoload

Wednesday, March 31, 2021
 
WooDzu
answered 7 Months ago
20

Ok, guys, I found the solution and want to share it with you: the spl_autoload_register() function has a third parameter: $prepend. When set to true, it will prepend the autoload function to the autoload queue, instead of appending it (it's actually documented at the official PHP Documentation). Composer always sets it to true, so that its autoloader is always called first. To fix it, I changed the legacy autoloader, setting $prepend to true, and called it AFTER including composer's autoload.

Hope it helps someone! :)

Saturday, May 29, 2021
 
SuperString
answered 5 Months ago
36

I believe the issue is that the autoloader file hasn't been generated so that it knows where to find the class. Try running

composer install

If you'd like to update the components of your website in the future, after the initial install, you can always run composer update to update the repositories.

Saturday, May 29, 2021
 
nomie
answered 5 Months ago
76

The trick is to use "sudo" command instead of "su"

You may need to add this

username1 ALL=(username2) NOPASSWD: /path/to/svn

to your /etc/sudoers file

and change your script to:

sudo -u username2 -H sh -c "cd /home/$USERNAME/$PROJECT; svn update" 

Where username2 is the user you want to run the SVN command as and username1 is the user running the script.

If you need multiple users to run this script, use a %groupname instead of the username1

Wednesday, June 2, 2021
 
Kenny
answered 5 Months ago
83

Babel by default assumes that files it processes are ES modules (using import and export). If you are running Babel on things in node_modules (which are likely CommonJS modules), you'll need to either tell Babel to process all node_modules as scripts, or tell Babel to guess the type based on the presence of import and export. Guessing is easiest, so you can add

sourceType: "unambiguous"

and also tell Babel not to run the usage transform on core-js itself with

  ignore: [
    //core-js/,
  ],

because otherwise the usage transform will actually be inserting references to core-js into itself causing dependency cycles.

So in your top-level Babel configuration, you'd do e.g.

{
  ignore: [
    //core-js/,
  ],
  sourceType: "unambiguous",
  presets: [
    ['@babel/preset-env', { modules: false, useBuiltIns: 'usage' }],
  ],
}

If you wanted to be extra specific about it, you could also do

{
  ignore: [
    //core-js/,
  ],
  presets: [
    ['@babel/preset-env', { modules: false, useBuiltIns: 'usage' }],
  ],
  overrides: [{
    test: "./node_modules",
    sourceType: "unambiguous",
  }],
}

to only set the flag for files inside node_modules, but there is likely not much to gain by doing that.

As for why this fixes that error, the issue is that, if Babel thinks something is an ES module, it will insert import statements. If you insert import statements into a file that also uses CommonJS things like module.exports, it means the file would now be using both module systems in the same file, which is a big issue and causes the errors you are seeing.

Monday, August 2, 2021
 
Sagar
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :