ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್: ಪರಿಹಾರ ತಂತ್ರಗಳೊಂದಿಗೆ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ನಿಭಾಯಿಸುವುದು

ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ವೆಬ್‌ಪ್ಯಾಕ್‌ನ ಒಂದು ಶಕ್ತಿಯುತ ವೈಶಿಷ್ಟ್ಯವಾಗಿದ್ದು, ಸ್ವತಂತ್ರವಾಗಿ ನಿಯೋಜಿಸಲಾದ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಕೋಡ್ ಹಂಚಿಕೊಳ್ಳಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ರಚಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅಲ್ಲಿ ವಿವಿಧ ತಂಡಗಳು ದೊಡ್ಡ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರತ್ಯೇಕ ಭಾಗಗಳನ್ನು ಹೊಂದಬಹುದು ಮತ್ತು ನಿಯೋಜಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಈ ವಿತರಣಾ ಸ್ವರೂಪವು ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ನಡುವೆ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. ಈ ಲೇಖನವು ಈ ಸಂಘರ್ಷಗಳ ಮೂಲ ಕಾರಣಗಳನ್ನು ಅನ್ವೇಷಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಹರಿಸಲು ಪರಿಣಾಮಕಾರಿ ತಂತ್ರಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಸೆಟಪ್‌ನಲ್ಲಿ, ವಿವಿಧ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು (ಹೋಸ್ಟ್‌ಗಳು ಮತ್ತು ರಿಮೋಟ್‌ಗಳು) ಒಂದೇ ರೀತಿಯ ಲೈಬ್ರರಿಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ರಿಯಾಕ್ಟ್, ಲೋಡಾಶ್) ಅವಲಂಬಿಸಿರಬಹುದು. ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದಾಗ ಮತ್ತು ನಿಯೋಜಿಸಿದಾಗ, ಅವು ಈ ಹಂಚಿದ ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಬಹುದು. ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಲೈಬ್ರರಿಯ ಹೊಂದಾಣಿಕೆಯಾಗದ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ ಇದು ರನ್‌ಟೈಮ್ ದೋಷಗಳಿಗೆ ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು. ಸಾಮಾನ್ಯ ಕಾರಣಗಳ ವಿಭಜನೆ ಇಲ್ಲಿದೆ:

• ವಿಭಿನ್ನ ಆವೃತ್ತಿಯ ಅವಶ್ಯಕತೆಗಳು: ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ package.json ಫೈಲ್‌ನಲ್ಲಿ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಾಗಿ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯ ಶ್ರೇಣಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ react: ^16.0.0 ಬೇಕಾಗಬಹುದು, ಇನ್ನೊಂದಕ್ಕೆ react: ^17.0.0 ಬೇಕಾಗಬಹುದು.
• ಟ್ರಾನ್ಸಿಟಿವ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳು: ಉನ್ನತ ಮಟ್ಟದ ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಸ್ಥಿರವಾಗಿದ್ದರೂ ಸಹ, ಟ್ರಾನ್ಸಿಟಿವ್ ಡಿಪೆಂಡೆನ್ಸಿಗಳು (ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಡಿಪೆಂಡೆನ್ಸಿಗಳು) ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಚಯಿಸಬಹುದು.
• ಅಸಂಗತ ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಗಳು: ವಿಭಿನ್ನ ಬಿಲ್ಡ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು ಅಥವಾ ಬಿಲ್ಡ್ ಪರಿಕರಗಳು ಅಂತಿಮ ಬಂಡಲ್‌ಗಳಲ್ಲಿ ಹಂಚಿದ ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಸೇರಿಸಲು ಕಾರಣವಾಗಬಹುದು.
• ಅಸಿಂಕ್ರೋನಸ್ ಲೋಡಿಂಗ್: ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ರಿಮೋಟ್ ಮಾಡ್ಯೂಲ್‌ಗಳ ಅಸಿಂಕ್ರೋನಸ್ ಲೋಡಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ ಹಂಚಿದ ಲೈಬ್ರರಿಯ ವಿಭಿನ್ನ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿರುವ ರಿಮೋಟ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿದರೆ, ರಿಮೋಟ್ ಮಾಡ್ಯೂಲ್ ಹಂಚಿದ ಲೈಬ್ರರಿಯನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಸಂಘರ್ಷ ಸಂಭವಿಸಬಹುದು.

ಉದಾಹರಣೆ ಸನ್ನಿವೇಶ

ನೀವು ಎರಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:

• ಹೋಸ್ಟ್ ಅಪ್ಲಿಕೇಶನ್ (ಆ್ಯಪ್ ಎ): ರಿಯಾಕ್ಟ್ ಆವೃತ್ತಿ 17.0.2 ಬಳಸುತ್ತದೆ.
• ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್ (ಆ್ಯಪ್ ಬಿ): ರಿಯಾಕ್ಟ್ ಆವೃತ್ತಿ 16.8.0 ಬಳಸುತ್ತದೆ.

ಆ್ಯಪ್ ಎ ಆ್ಯಪ್ ಬಿ ಅನ್ನು ರಿಮೋಟ್ ಮಾಡ್ಯೂಲ್ ಆಗಿ ಬಳಸುತ್ತದೆ. ಆ್ಯಪ್ ಎ, ಆ್ಯಪ್ ಬಿ ಯಿಂದ ಒಂದು ಕಾಂಪೊನೆಂಟ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅದು ರಿಯಾಕ್ಟ್ 16.8.0 ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, ಅದು ದೋಷಗಳನ್ನು ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಯನ್ನು ಎದುರಿಸಬಹುದು ಏಕೆಂದರೆ ಆ್ಯಪ್ ಎ ರಿಯಾಕ್ಟ್ 17.0.2 ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ.

ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸುವ ತಂತ್ರಗಳು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಲು ಹಲವಾರು ತಂತ್ರಗಳನ್ನು ಬಳಸಬಹುದು. ಉತ್ತಮ ವಿಧಾನವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿರ್ದಿಷ್ಟ ಅವಶ್ಯಕತೆಗಳು ಮತ್ತು ಸಂಘರ್ಷಗಳ ಸ್ವರೂಪವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

1. ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚಿಕೊಳ್ಳುವುದು

ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಯಾವ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಘೋಷಿಸುವುದು ಅತ್ಯಂತ ಮೂಲಭೂತ ಹಂತವಾಗಿದೆ. ಇದನ್ನು ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್‌ಗಳಿಗಾಗಿ ವೆಬ್‌ಪ್ಯಾಕ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ shared ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ ಮಾಡಲಾಗುತ್ತದೆ.

// webpack.config.js (ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್)
module.exports = {
  // ... ಇತರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು
  plugins: [
    new ModuleFederationPlugin({
      // ... ಇತರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು
      shared: {
        react: {
          singleton: true,
          eager: true,
          requiredVersion: '^17.0.0', // ಅಥವಾ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿ ಶ್ರೇಣಿ
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^17.0.0',
        },
        // ಇತರ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳು
      },
    }),
  ],
};

shared ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ವಿಭಜಿಸೋಣ:

• singleton: true: ಇದು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಾದ್ಯಂತ ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನ ಒಂದೇ ಒಂದು ನಿದರ್ಶನವನ್ನು (instance) ಬಳಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದು ರಿಯಾಕ್ಟ್‌ನಂತಹ ಲೈಬ್ರರಿಗಳಿಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ, ಅಲ್ಲಿ ಅನೇಕ ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಿರುವುದು ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಇದನ್ನು true ಗೆ ಹೊಂದಿಸುವುದರಿಂದ, ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳು ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದರೆ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ.
• eager: true: ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಲೇಜಿಯಾಗಿ (lazily) ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ. eager ಅನ್ನು true ಗೆ ಹೊಂದಿಸುವುದರಿಂದ ಹಂಚಿದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ತಕ್ಷಣವೇ ಲೋಡ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುತ್ತದೆ, ಇದು ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳಿಂದ ಉಂಟಾಗುವ ರನ್‌ಟೈಮ್ ದೋಷಗಳನ್ನು ತಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• requiredVersion: '^17.0.0': ಇದು ಅಗತ್ಯವಿರುವ ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನ ಕನಿಷ್ಠ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ. ಇದು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಆವೃತ್ತಿ ಹೊಂದಾಣಿಕೆಯನ್ನು ಜಾರಿಗೊಳಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಪ್ಯಾಚ್ ಅಪ್‌ಡೇಟ್‌ಗಳಿಗೆ ಅವಕಾಶ ನೀಡಲು ಒಂದೇ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯ ಬದಲು ನಿರ್ದಿಷ್ಟ ಆವೃತ್ತಿ ಶ್ರೇಣಿಯನ್ನು (ಉದಾ., ^17.0.0 ಅಥವಾ >=17.0.0 <18.0.0) ಬಳಸುವುದು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಇದು ವಿಶೇಷವಾಗಿ ನಿರ್ಣಾಯಕವಾಗಿದೆ, ಅಲ್ಲಿ ಅನೇಕ ತಂಡಗಳು ಒಂದೇ ಡಿಪೆಂಡೆನ್ಸಿಯ ವಿಭಿನ್ನ ಪ್ಯಾಚ್ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಬಹುದು.

2. ಸೆಮ್ಯಾಂಟಿಕ್ ಆವೃತ್ತಿ (SemVer) ಮತ್ತು ಆವೃತ್ತಿ ಶ್ರೇಣಿಗಳು

ಸೆಮ್ಯಾಂಟಿಕ್ ಆವೃತ್ತಿ (SemVer) ತತ್ವಗಳಿಗೆ ಬದ್ಧವಾಗಿರುವುದು ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಅತ್ಯಗತ್ಯ. SemVer ಮೂರು-ಭಾಗಗಳ ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯನ್ನು (MAJOR.MINOR.PATCH) ಬಳಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಭಾಗವನ್ನು ಹೆಚ್ಚಿಸಲು ನಿಯಮಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ:

• MAJOR: ನೀವು ಹೊಂದಾಣಿಕೆಯಾಗದ API ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ.
• MINOR: ನೀವು ಹಿಮ್ಮುಖವಾಗಿ ಹೊಂದಾಣಿಕೆಯಾಗುವ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಿದಾಗ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ.
• PATCH: ನೀವು ಹಿಮ್ಮುಖವಾಗಿ ಹೊಂದಾಣಿಕೆಯಾಗುವ ದೋಷ ಪರಿಹಾರಗಳನ್ನು ಮಾಡಿದಾಗ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ.

ನಿಮ್ಮ package.json ಫೈಲ್‌ನಲ್ಲಿ ಅಥವಾ shared ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಆವೃತ್ತಿಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವಾಗ, ಬ್ರೇಕಿಂಗ್ ಬದಲಾವಣೆಗಳನ್ನು ತಪ್ಪಿಸುತ್ತಾ ಹೊಂದಾಣಿಕೆಯಾಗುವ ನವೀಕರಣಗಳಿಗೆ ಅವಕಾಶ ನೀಡಲು ಆವೃತ್ತಿ ಶ್ರೇಣಿಗಳನ್ನು (ಉದಾ., ^17.0.0, >=17.0.0 <18.0.0, ~17.0.2) ಬಳಸಿ. ಸಾಮಾನ್ಯ ಆವೃತ್ತಿ ಶ್ರೇಣಿ ಆಪರೇಟರ್‌ಗಳ ಒಂದು ತ್ವರಿತ ಜ್ಞಾಪನೆ ಇಲ್ಲಿದೆ:

• ^ (ಕ್ಯಾರೆಟ್): ಎಡಭಾಗದ ಶೂನ್ಯವಲ್ಲದ ಅಂಕಿಯನ್ನು ಮಾರ್ಪಡಿಸದ ನವೀಕರಣಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ^1.2.3 ಆವೃತ್ತಿಗಳು 1.2.4, 1.3.0 ಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ 2.0.0 ಗೆ ಅಲ್ಲ. ^0.2.3 ಆವೃತ್ತಿಗಳು 0.2.4 ಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ 0.3.0 ಗೆ ಅಲ್ಲ.
• ~ (ಟಿಲ್ಡೆ): ಪ್ಯಾಚ್ ನವೀಕರಣಗಳಿಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ~1.2.3 ಆವೃತ್ತಿಗಳು 1.2.4 ಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ 1.3.0 ಗೆ ಅಲ್ಲ.
• >=: ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಥವಾ ಸಮಾನ.
• <=: ಅದಕ್ಕಿಂತ ಕಡಿಮೆ ಅಥವಾ ಸಮಾನ.
• >: ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು.
• <: ಅದಕ್ಕಿಂತ ಕಡಿಮೆ.
• =: ನಿಖರವಾಗಿ ಸಮಾನ.
• *: ಯಾವುದೇ ಆವೃತ್ತಿ. ಉತ್ಪಾದನೆಯಲ್ಲಿ * ಬಳಸುವುದನ್ನು ತಪ್ಪಿಸಿ ಏಕೆಂದರೆ ಇದು ಅನಿರೀಕ್ಷಿತ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು.

3. ಡಿಪೆಂಡೆನ್ಸಿ ಡಿಡ್ಯೂಪ್ಲಿಕೇಶನ್

npm dedupe ಅಥವಾ yarn dedupe ನಂತಹ ಪರಿಕರಗಳು ನಿಮ್ಮ node_modules ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ನಕಲಿ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ತೆಗೆದುಹಾಕಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಇದು ಪ್ರತಿಯೊಂದು ಡಿಪೆಂಡೆನ್ಸಿಯ ಒಂದೇ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಮೂಲಕ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಈ ಕಮಾಂಡ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿ:

npm dedupe
yarn dedupe

4. ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಸುಧಾರಿತ ಹಂಚಿಕೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸುವುದು

ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಹೆಚ್ಚು ಸುಧಾರಿತ ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ಆಯ್ಕೆಗಳು ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಹೇಗೆ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಪರಿಹರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಕ್ಷ್ಮವಾಗಿ ಸರಿಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

• version: ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನ ನಿಖರವಾದ ಆವೃತ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• import: ಹಂಚಿಕೊಳ್ಳಬೇಕಾದ ಮಾಡ್ಯೂಲ್‌ಗೆ ಮಾರ್ಗವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• shareKey: ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ವಿಭಿನ್ನ ಕೀಲಿಯನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ಒಂದೇ ಮಾಡ್ಯೂಲ್‌ನ ಅನೇಕ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಅವುಗಳನ್ನು ವಿಭಿನ್ನ ಹೆಸರುಗಳ ಅಡಿಯಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಬೇಕಾದರೆ ಇದು ಉಪಯುಕ್ತವಾಗಿರುತ್ತದೆ.
• shareScope: ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕಾದ ವ್ಯಾಪ್ತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
• strictVersion: true ಗೆ ಹೊಂದಿಸಿದರೆ, ಹಂಚಿದ ಮಾಡ್ಯೂಲ್‌ನ ಆವೃತ್ತಿಯು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಆವೃತ್ತಿಗೆ ನಿಖರವಾಗಿ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ದೋಷವನ್ನು ನೀಡುತ್ತದೆ.

shareKey ಮತ್ತು import ಆಯ್ಕೆಗಳನ್ನು ಬಳಸುವ ಒಂದು ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

// webpack.config.js (ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್)
module.exports = {
  // ... ಇತರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು
  plugins: [
    new ModuleFederationPlugin({
      // ... ಇತರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳು
      shared: {
        react16: {
          import: 'react',
          shareKey: 'react',
          singleton: true,
          requiredVersion: '^16.0.0',
        },
        react17: {
          import: 'react',
          shareKey: 'react',
          singleton: true,
          requiredVersion: '^17.0.0',
        },
      },
    }),
  ],
};

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ರಿಯಾಕ್ಟ್ 16 ಮತ್ತು ರಿಯಾಕ್ಟ್ 17 ಎರಡನ್ನೂ ಒಂದೇ shareKey ('react') ಅಡಿಯಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ. ಇದು ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಂಘರ್ಷಗಳನ್ನು ಉಂಟುಮಾಡದೆ ರಿಯಾಕ್ಟ್‌ನ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ವಿಧಾನವನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕು ಏಕೆಂದರೆ ಇದು ಬಂಡಲ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಮತ್ತು ವಿಭಿನ್ನ ರಿಯಾಕ್ಟ್ ಆವೃತ್ತಿಗಳು ನಿಜವಾಗಿಯೂ ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದರೆ ಸಂಭಾವ್ಯ ರನ್‌ಟೈಮ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಾ ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್‌ಗಳಾದ್ಯಂತ ಒಂದೇ ರಿಯಾಕ್ಟ್ ಆವೃತ್ತಿಯಲ್ಲಿ ಪ್ರಮಾಣೀಕರಿಸುವುದು ಉತ್ತಮ.

5. ಕೇಂದ್ರೀಕೃತ ಡಿಪೆಂಡೆನ್ಸಿ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವುದು

ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್‌ಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಅನೇಕ ತಂಡಗಳನ್ನು ಹೊಂದಿರುವ ದೊಡ್ಡ ಸಂಸ್ಥೆಗಳಿಗೆ, ಕೇಂದ್ರೀಕೃತ ಡಿಪೆಂಡೆನ್ಸಿ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯು ಅಮೂಲ್ಯವಾಗಿರುತ್ತದೆ. ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳಿಗಾಗಿ ಸ್ಥಿರ ಆವೃತ್ತಿಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ಮತ್ತು ಜಾರಿಗೊಳಿಸಲು ಬಳಸಬಹುದು. pnpm (ಅದರ ಹಂಚಿದ node_modules ತಂತ್ರದೊಂದಿಗೆ) ಅಥವಾ ಕಸ್ಟಮ್ ಪರಿಹಾರಗಳಂತಹ ಪರಿಕರಗಳು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹಂಚಿದ ಲೈಬ್ರರಿಗಳ ಹೊಂದಾಣಿಕೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಬಳಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಉದಾಹರಣೆ: pnpm

pnpm ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಕಂಟೆಂಟ್-ಅಡ್ರೆಸ್ಸಬಲ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ನೀವು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದಾಗ, pnpm ಅದರ ಸ್ಟೋರ್‌ನಲ್ಲಿರುವ ಪ್ಯಾಕೇಜ್‌ಗೆ ಹಾರ್ಡ್ ಲಿಂಕ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಇದರರ್ಥ ಅನೇಕ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಫೈಲ್‌ಗಳನ್ನು ನಕಲು ಮಾಡದೆ ಒಂದೇ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು. ಇದು ಡಿಸ್ಕ್ ಸ್ಥಳವನ್ನು ಉಳಿಸಬಹುದು ಮತ್ತು ಅನುಸ್ಥಾಪನಾ ವೇಗವನ್ನು ಸುಧಾರಿಸಬಹುದು. ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿ, ಇದು ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಾದ್ಯಂತ ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

pnpm ನೊಂದಿಗೆ ಸ್ಥಿರ ಆವೃತ್ತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು, ನೀವು pnpmfile.js ಫೈಲ್ ಅನ್ನು ಬಳಸಬಹುದು. ಈ ಫೈಲ್ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಸ್ಥಾಪಿಸುವ ಮೊದಲು ಅವುಗಳನ್ನು ಮಾರ್ಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಒಂದೇ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಆವೃತ್ತಿಗಳನ್ನು ಅತಿಕ್ರಮಿಸಲು (override) ನೀವು ಇದನ್ನು ಬಳಸಬಹುದು.

// pnpmfile.js
module.exports = {
  hooks: {
    readPackage(pkg) {
      if (pkg.dependencies && pkg.dependencies.react) {
        pkg.dependencies.react = '^17.0.0';
      }
      if (pkg.devDependencies && pkg.devDependencies.react) {
        pkg.devDependencies.react = '^17.0.0';
      }
      return pkg;
    },
  },
};

6. ರನ್‌ಟೈಮ್ ಆವೃತ್ತಿ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು

ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಬಿಲ್ಡ್ ಸಮಯದಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕಲು ಸಾಧ್ಯವಾಗದಿರಬಹುದು. ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನೀವು ರನ್‌ಟೈಮ್ ಆವೃತ್ತಿ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಇದು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಹಂಚಿದ ಲೈಬ್ರರಿಯ ಆವೃತ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದನ್ನು ಮತ್ತು ಆವೃತ್ತಿಯು ಹೊಂದಾಣಿಕೆಯಾಗದಿದ್ದರೆ ಪರ್ಯಾಯ ಕೋಡ್ ಮಾರ್ಗಗಳನ್ನು ಒದಗಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇದು ಸಂಕೀರ್ಣವಾಗಬಹುದು ಮತ್ತು ಹೆಚ್ಚುವರಿ ಹೊರೆ ಸೇರಿಸಬಹುದು ಆದರೆ ಕೆಲವು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಅಗತ್ಯ ತಂತ್ರವಾಗಿದೆ.

// ಉದಾಹರಣೆ: ರನ್‌ಟೈಮ್ ಆವೃತ್ತಿ ಪರಿಶೀಲನೆ
import React from 'react';

function MyComponent() {
  if (React.version && React.version.startsWith('16')) {
    // ರಿಯಾಕ್ಟ್ 16 ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ಬಳಸಿ
    return <div>React 16 Component</div>;
  } else if (React.version && React.version.startsWith('17')) {
    // ರಿಯಾಕ್ಟ್ 17 ನಿರ್ದಿಷ್ಟ ಕೋಡ್ ಬಳಸಿ
    return <div>React 17 Component</div>;
  } else {
    // ಫಾಲ್‌ಬ್ಯಾಕ್ ಒದಗಿಸಿ
    return <div>Unsupported React version</div>;
  }
}

export default MyComponent;

ಪ್ರಮುಖ ಪರಿಗಣನೆಗಳು:

• ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ: ರನ್‌ಟೈಮ್ ಪರಿಶೀಲನೆಗಳು ಹೆಚ್ಚುವರಿ ಹೊರೆ ಸೇರಿಸುತ್ತವೆ. ಅವುಗಳನ್ನು ಮಿತವಾಗಿ ಬಳಸಿ.
• ಸಂಕೀರ್ಣತೆ: ಅನೇಕ ಕೋಡ್ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ಕೋಡ್ ಸಂಕೀರ್ಣತೆ ಮತ್ತು ನಿರ್ವಹಣಾ ಹೊರೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.
• ಪರೀಕ್ಷೆ: ಹಂಚಿದ ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಸರಿಯಾಗಿ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಎಲ್ಲಾ ಕೋಡ್ ಮಾರ್ಗಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಿ.

7. ಪರೀಕ್ಷೆ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ (Continuous Integration)

ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಪರಿಹರಿಸಲು ಸಮಗ್ರ ಪರೀಕ್ಷೆಯು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಹೋಸ್ಟ್ ಮತ್ತು ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವಿನ ಸಂವಾದವನ್ನು ಅನುಕರಿಸುವ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು (integration tests) ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಈ ಪರೀಕ್ಷೆಗಳು ಹಂಚಿದ ಲೈಬ್ರರಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳನ್ನು ಒಳಗೊಂಡಿರಬೇಕು. ಕೋಡ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗಲೆಲ್ಲಾ ದೃಢವಾದ ನಿರಂತರ ಏಕೀಕರಣ (CI) ವ್ಯವಸ್ಥೆಯು ಈ ಪರೀಕ್ಷೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಚಲಾಯಿಸಬೇಕು. ಇದು ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯ ಆರಂಭದಲ್ಲೇ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

CI ಪೈಪ್‌ಲೈನ್ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು:

• ವಿಭಿನ್ನ ಡಿಪೆಂಡೆನ್ಸಿ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಿ: ನಿಮ್ಮ CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಪರೀಕ್ಷೆಗಳನ್ನು ಚಲಾಯಿಸಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಇದು ಉತ್ಪಾದನೆಯನ್ನು ತಲುಪುವ ಮೊದಲು ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಸ್ವಯಂಚಾಲಿತ ಡಿಪೆಂಡೆನ್ಸಿ ನವೀಕರಣಗಳು: ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಲು ಮತ್ತು ಪುಲ್ ವಿನಂತಿಗಳನ್ನು (pull requests) ರಚಿಸಲು ರೆನೋವೇಟ್ ಅಥವಾ ಡಿಪೆಂಡಾಬೋಟ್‌ನಂತಹ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ. ಇದು ನಿಮ್ಮ ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ನವೀಕೃತವಾಗಿರಿಸಲು ಮತ್ತು ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
• ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ (Static Analysis): ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಸಂಭಾವ್ಯ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಗುರುತಿಸಲು ಸ್ಥಿರ ವಿಶ್ಲೇಷಣೆ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ.

ನೈಜ-ಪ್ರಪಂಚದ ಉದಾಹರಣೆಗಳು ಮತ್ತು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ಈ ತಂತ್ರಗಳನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ನೈಜ-ಪ್ರಪಂಚದ ಉದಾಹರಣೆಗಳನ್ನು ಪರಿಗಣಿಸೋಣ:

• ಸನ್ನಿವೇಶ 1: ದೊಡ್ಡ ಇ-ಕಾಮರ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್

  ದೊಡ್ಡ ಇ-ಕಾಮರ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತನ್ನ ಸ್ಟೋರ್‌ಫ್ರಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ವಿಭಿನ್ನ ತಂಡಗಳು ಉತ್ಪನ್ನ ಪಟ್ಟಿ ಪುಟ, ಶಾಪಿಂಗ್ ಕಾರ್ಟ್, ಮತ್ತು ಚೆಕ್‌ಔಟ್ ಪುಟದಂತಹ ಸ್ಟೋರ್‌ಫ್ರಂಟ್‌ನ ವಿಭಿನ್ನ ಭಾಗಗಳನ್ನು ಹೊಂದಿವೆ. ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ತಪ್ಪಿಸಲು, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ pnpm ಆಧಾರಿತ ಕೇಂದ್ರೀಕೃತ ಡಿಪೆಂಡೆನ್ಸಿ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುತ್ತದೆ. ಎಲ್ಲಾ ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್‌ಗಳಾದ್ಯಂತ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಸ್ಥಿರ ಆವೃತ್ತಿಗಳನ್ನು ಜಾರಿಗೊಳಿಸಲು pnpmfile.js ಫೈಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವಿಭಿನ್ನ ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್‌ಗಳ ನಡುವಿನ ಸಂವಾದವನ್ನು ಅನುಕರಿಸುವ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಸಮಗ್ರ ಪರೀಕ್ಷಾ ಸೂಟ್ ಅನ್ನು ಸಹ ಹೊಂದಿದೆ. ಡಿಪೆಂಡಾಬೋಟ್ ಮೂಲಕ ಸ್ವಯಂಚಾಲಿತ ಡಿಪೆಂಡೆನ್ಸಿ ನವೀಕರಣಗಳನ್ನು ಸಹ ಡಿಪೆಂಡೆನ್ಸಿ ಆವೃತ್ತಿಗಳನ್ನು ಪೂರ್ವಭಾವಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.

• ಸನ್ನಿವೇಶ 2: ಹಣಕಾಸು ಸೇವೆಗಳ ಅಪ್ಲಿಕೇಶನ್

  ಹಣಕಾಸು ಸೇವೆಗಳ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಖಾತೆ ಅವಲೋಕನ ಪುಟ, ವಹಿವಾಟು ಇತಿಹಾಸ ಪುಟ, ಮತ್ತು ಹೂಡಿಕೆ ಪೋರ್ಟ್‌ಫೋಲಿಯೊ ಪುಟದಂತಹ ಹಲವಾರು ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್‌ಗಳಿಂದ ಕೂಡಿದೆ. ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಯಂತ್ರಕ ಅವಶ್ಯಕತೆಗಳಿಂದಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಕೆಲವು ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕಾಗುತ್ತದೆ. ಇದನ್ನು ಪರಿಹರಿಸಲು, ಅಪ್ಲಿಕೇಶನ್ ರನ್‌ಟೈಮ್ ಆವೃತ್ತಿ ಪರಿಶೀಲನೆಗಳು ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ವಿಭಿನ್ನ ಬ್ರೌಸರ್‌ಗಳು ಮತ್ತು ಸಾಧನಗಳಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಪರೀಕ್ಷೆಯನ್ನು ಒಳಗೊಂಡಿರುವ ಕಠಿಣ ಪರೀಕ್ಷಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಹ ಹೊಂದಿದೆ.

• ಸನ್ನಿವೇಶ 3: ಜಾಗತಿಕ ಸಹಯೋಗ ವೇದಿಕೆ (Global Collaboration Platform)

  ಉತ್ತರ ಅಮೇರಿಕಾ, ಯುರೋಪ್, ಮತ್ತು ಏಷ್ಯಾದಾದ್ಯಂತದ ಕಚೇರಿಗಳಲ್ಲಿ ಬಳಸಲಾಗುವ ಜಾಗತಿಕ ಸಹಯೋಗ ವೇದಿಕೆಯು ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಕೋರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡವು ಲಾಕ್ ಮಾಡಲಾದ ಆವೃತ್ತಿಗಳೊಂದಿಗೆ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ಕಟ್ಟುನಿಟ್ಟಾದ ಗುಂಪನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ರಿಮೋಟ್ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಪ್ರತ್ಯೇಕ ವೈಶಿಷ್ಟ್ಯ ತಂಡಗಳು ಈ ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿ ಆವೃತ್ತಿಗಳಿಗೆ ಬದ್ಧವಾಗಿರಬೇಕು. ಎಲ್ಲಾ ತಂಡಗಳಾದ್ಯಂತ ಸ್ಥಿರ ಬಿಲ್ಡ್ ಪರಿಸರವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ಬಳಸಿ ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿದೆ. CI/CD ಪೈಪ್‌ಲೈನ್ ವ್ಯಾಪಕವಾದ ಏಕೀಕರಣ ಪರೀಕ್ಷೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಅದು ವಿವಿಧ ಬ್ರೌಸರ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳ ವಿರುದ್ಧ ಚಲಿಸುತ್ತದೆ, ವಿಭಿನ್ನ ಪ್ರಾದೇಶಿಕ ಅಭಿವೃದ್ಧಿ ಪರಿಸರಗಳಿಂದ ಉಂಟಾಗುವ ಯಾವುದೇ ಸಂಭಾವ್ಯ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳು ಅಥವಾ ಹೊಂದಾಣಿಕೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು.

ತೀರ್ಮಾನ

ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್ ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ಶಕ್ತಿಯುತ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹಂಚಿದ ಡಿಪೆಂಡೆನ್ಸಿಗಳ ನಡುವಿನ ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳ ಸಂಭಾವ್ಯತೆಯನ್ನು ಪರಿಹರಿಸುವುದು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಡಿಪೆಂಡೆನ್ಸಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚಿಕೊಳ್ಳುವುದು, ಸೆಮ್ಯಾಂಟಿಕ್ ಆವೃತ್ತಿಗೆ ಬದ್ಧವಾಗಿರುವುದು, ಡಿಪೆಂಡೆನ್ಸಿ ಡಿಡ್ಯೂಪ್ಲಿಕೇಶನ್ ಪರಿಕರಗಳನ್ನು ಬಳಸುವುದು, ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಸುಧಾರಿತ ಹಂಚಿಕೆ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು, ಮತ್ತು ದೃಢವಾದ ಪರೀಕ್ಷೆ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ ಅಭ್ಯಾಸಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ, ನೀವು ಆವೃತ್ತಿ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಭಾಯಿಸಬಹುದು ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮತ್ತು ದೃಢವಾದ ಮೈಕ್ರೋ ಫ್ರಂಟೆಂಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು. ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಗಾತ್ರ, ಸಂಕೀರ್ಣತೆ, ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳಿಗೆ ಉತ್ತಮವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುವ ತಂತ್ರಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಮರೆಯದಿರಿ. ಮಾಡ್ಯೂಲ್ ಫೆಡರೇಶನ್‌ನ ಪ್ರಯೋಜನಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸಿಕೊಳ್ಳಲು ಡಿಪೆಂಡೆನ್ಸಿ ನಿರ್ವಹಣೆಗೆ ಪೂರ್ವಭಾವಿ ಮತ್ತು ಉತ್ತಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ವಿಧಾನವು ಅತ್ಯಗತ್ಯ.