ವರ್ಡ್ಪ್ರೆಸ್

PHP ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡಲು ಅಂತಿಮ ಮಾರ್ಗದರ್ಶಿ

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

ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾವು ಇತ್ತೀಚಿನ PHP ಕೋಡ್ ಅನ್ನು ಬಳಸುವ ಭರವಸೆಯನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಆದರೆ ಉತ್ತಮ ಪರ್ಯಾಯವಿದೆ: ನಾವು ಇನ್ನೂ ನಮ್ಮ ಮೂಲ ಕೋಡ್ ಅನ್ನು PHP 8.0 ನೊಂದಿಗೆ ಬರೆಯಬಹುದು ಮತ್ತು ಅದನ್ನು ಹಿಂದಿನ PHP ಆವೃತ್ತಿಗೆ - PHP 7.1 ಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದು.

ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ, PHP ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ಕುರಿತು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ನಾವು ನಿಮಗೆ ಕಲಿಸುತ್ತೇವೆ.

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಎಂದರೇನು?

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯಿಂದ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅದೇ ಅಥವಾ ಬೇರೆ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಯ ಸಮಾನ ಮೂಲ ಕೋಡ್‌ಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ವೆಬ್ ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಹೊಸ ಪರಿಕಲ್ಪನೆಯಲ್ಲ: ಕ್ಲೈಂಟ್-ಸೈಡ್ ಡೆವಲಪರ್‌ಗಳು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್‌ಗಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲರ್ ಬ್ಯಾಬೆಲ್‌ನೊಂದಿಗೆ ಸಾಕಷ್ಟು ಪರಿಚಿತರಾಗಿರುತ್ತಾರೆ.

Babel ಆಧುನಿಕ ECMAScript 2015+ ಆವೃತ್ತಿಯಿಂದ JavaScript ಕೋಡ್ ಅನ್ನು ಹಳೆಯ ಬ್ರೌಸರ್‌ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಪರಂಪರೆಯ ಆವೃತ್ತಿಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ES2015 ಬಾಣದ ಕಾರ್ಯವನ್ನು ನೀಡಲಾಗಿದೆ:

[2, 4, 6].map((n) => n * 2);

…Babel ಅದನ್ನು ತನ್ನ ES5 ಆವೃತ್ತಿಗೆ ಪರಿವರ್ತಿಸುತ್ತದೆ:

[2, 4, 6].map(function(n) {
  return n * 2;
});

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡುವುದು ಎಂದರೇನು?

ವೆಬ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಂಭಾವ್ಯವಾಗಿ ಹೊಸದೇನೆಂದರೆ ಸರ್ವರ್-ಸೈಡ್ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ಸಾಧ್ಯತೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ PHP.

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡುವುದು JavaScript ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ರೀತಿಯಲ್ಲಿಯೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಆಧುನಿಕ PHP ಆವೃತ್ತಿಯಿಂದ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಹಳೆಯ PHP ಆವೃತ್ತಿಗೆ ಸಮಾನವಾದ ಕೋಡ್‌ಗೆ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ.

ಮೊದಲಿನಂತೆಯೇ ಅದೇ ಉದಾಹರಣೆಯನ್ನು ಅನುಸರಿಸಿ, PHP 7.4 ನಿಂದ ಬಾಣದ ಕಾರ್ಯ:

$nums = array_map(fn($n) => $n * 2, [2, 4, 6]);

…ಅದರ ಸಮಾನವಾದ PHP 7.3 ಆವೃತ್ತಿಗೆ ವರ್ಗಾಯಿಸಬಹುದು:

$nums = array_map(
  function ($n) {
    return $n * 2;
  },
  [2, 4, 6]
);

ಬಾಣದ ಕಾರ್ಯಗಳನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದು ಏಕೆಂದರೆ ಅವು ವಾಕ್ಯರಚನೆಯ ಸಕ್ಕರೆ, ಅಂದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಡವಳಿಕೆಯನ್ನು ಉತ್ಪಾದಿಸಲು ಹೊಸ ಸಿಂಟ್ಯಾಕ್ಸ್. ಇದು ಕಡಿಮೆ ನೇತಾಡುವ ಹಣ್ಣು.

ಆದಾಗ್ಯೂ, ಹೊಸ ನಡವಳಿಕೆಯನ್ನು ರಚಿಸುವ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಸಹ ಇವೆ, ಮತ್ತು PHP ಯ ಹಿಂದಿನ ಆವೃತ್ತಿಗಳಿಗೆ ಸಮಾನವಾದ ಕೋಡ್ ಇರುವುದಿಲ್ಲ. PHP 8.0 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾದ ಯೂನಿಯನ್ ಪ್ರಕಾರಗಳಲ್ಲಿ ಅದು ಹೀಗಿದೆ:

function someFunction(float|int $param): string|float|int|null
{
  // ...
}

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

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

ಆದ್ದರಿಂದ, ಉತ್ಪಾದನೆಗಾಗಿ ಕೋಡ್‌ನಿಂದ ವೈಶಿಷ್ಟ್ಯವನ್ನು ತೆಗೆದುಹಾಕಲು ನಾವು ಶಕ್ತರಾಗಿದ್ದೇವೆ:

function someFunction($param)
{
  // ...
}

ದೋಷವು ಇನ್ನೂ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಾವು ಯೂನಿಯನ್ ಪ್ರಕಾರಗಳನ್ನು ಹೊಂದಿದ್ದಕ್ಕಿಂತ ಎಸೆದ ದೋಷ ಸಂದೇಶವು ಕಡಿಮೆ ನಿಖರವಾಗಿರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ಸಂಭಾವ್ಯ ಅನನುಕೂಲತೆಯು ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿ ಯೂನಿಯನ್ ಪ್ರಕಾರಗಳನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುವ ಮೂಲಕ ಮೀರಿಸುತ್ತದೆ.

ಪರಿಪೂರ್ಣ ಜಗತ್ತಿನಲ್ಲಿ, ನಾವು ನಮ್ಮ ಎಲ್ಲಾ ಸೈಟ್‌ಗಳಲ್ಲಿ PHP 8.0 ಅನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದ ತಕ್ಷಣ ಅದನ್ನು ನವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ 😌 ಆದರೆ ಅದು ಯಾವಾಗಲೂ ಅಲ್ಲ. PHP ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ಬಗ್ಗೆ ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಇಲ್ಲಿ ತಿಳಿಯಿರಿ 👇ಟ್ವೀಟ್ ಮಾಡಲು ಕ್ಲಿಕ್ ಮಾಡಿ

PHP ಕೋಡ್ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್‌ನ ಪ್ರಯೋಜನಗಳು

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ PHP ಯ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕೋಡ್ ಮಾಡಲು ಒಬ್ಬರನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತದೆ ಮತ್ತು PHP ಯ ಹಳೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಚಾಲನೆಯಲ್ಲಿರುವ ಪರಿಸರದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬಿಡುಗಡೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ.

ಪಾರಂಪರಿಕ ವಿಷಯ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ (CMS) ಉತ್ಪನ್ನಗಳನ್ನು ರಚಿಸುವ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ. ವರ್ಡ್ಪ್ರೆಸ್, ಉದಾಹರಣೆಗೆ, ಇನ್ನೂ ಅಧಿಕೃತವಾಗಿ PHP 5.6 ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ (ಇದು PHP 7.4+ ಅನ್ನು ಶಿಫಾರಸು ಮಾಡಿದರೂ ಸಹ). PHP ಆವೃತ್ತಿಗಳು 5.6 ರಿಂದ 7.2 ರನ್ ಆಗುತ್ತಿರುವ ವರ್ಡ್ಪ್ರೆಸ್ ಸೈಟ್‌ಗಳ ಶೇಕಡಾವಾರು - ಇವೆಲ್ಲವೂ ಎಂಡ್-ಆಫ್-ಲೈಫ್ (EOL), ಅಂದರೆ ಅವರು ಇನ್ನು ಮುಂದೆ ಭದ್ರತಾ ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಿಲ್ಲ - ಗಣನೀಯ ಪ್ರಮಾಣದಲ್ಲಿ 34.8% ಮತ್ತು ಯಾವುದೇ PHP ಆವೃತ್ತಿಯಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿದೆ. 8.0 ಅಗಾಧವಾದ 99.5% ನಲ್ಲಿ ನಿಂತಿದೆ:

ಆವೃತ್ತಿಯ ಮೂಲಕ ವರ್ಡ್ಪ್ರೆಸ್ ಬಳಕೆ
ಆವೃತ್ತಿಯ ಮೂಲಕ ವರ್ಡ್ಪ್ರೆಸ್ ಬಳಕೆಯ ಅಂಕಿಅಂಶಗಳು. ಚಿತ್ರ ಮೂಲ: WordPress

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

ವಾಸ್ತವವಾಗಿ, ತೀರಾ ಇತ್ತೀಚಿನದನ್ನು ಹೊರತುಪಡಿಸಿ ಯಾವುದೇ PHP ಆವೃತ್ತಿಯನ್ನು ಬೆಂಬಲಿಸುವ ಅಗತ್ಯವಿರುವ ಯಾವುದೇ ಅಪ್ಲಿಕೇಶನ್ (ಪ್ರಸ್ತುತ ಬೆಂಬಲಿತ PHP ಆವೃತ್ತಿಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿಯೂ ಸಹ) ಪ್ರಯೋಜನ ಪಡೆಯಬಹುದು.

PHP 7.3 ಅಗತ್ಯವಿರುವ Drupal ನೊಂದಿಗೆ ಇದು ಸಂಭವಿಸುತ್ತದೆ. ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ಡೆವಲಪರ್‌ಗಳು PHP 8.0 ಬಳಸಿಕೊಂಡು ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ Drupal ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ರಚಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು PHP 7.3 ನೊಂದಿಗೆ ಬಿಡುಗಡೆ ಮಾಡಬಹುದು.

ಒಂದು ಕಾರಣ ಅಥವಾ ಇನ್ನೊಂದು ಕಾರಣದಿಂದ ತಮ್ಮ ಪರಿಸರದಲ್ಲಿ PHP 8.0 ಅನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಕಸ್ಟಮ್ ಕೋಡ್ ರಚಿಸುವಾಗ ಮತ್ತೊಂದು ಉದಾಹರಣೆಯಾಗಿದೆ. ಅದೇನೇ ಇದ್ದರೂ, ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್‌ಗೆ ಧನ್ಯವಾದಗಳು, ಡೆವಲಪರ್‌ಗಳು ಇನ್ನೂ PHP 8.0 ಅನ್ನು ಬಳಸಿಕೊಂಡು ತಮ್ಮ ವಿತರಣೆಗಳನ್ನು ಕೋಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಆ ಪರಂಪರೆಯ ಪರಿಸರದಲ್ಲಿ ಅವುಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು.

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ಯಾವಾಗ

PHP ಯ ಹಿಂದಿನ ಆವೃತ್ತಿಯಲ್ಲಿ ಯಾವುದೇ ಸಮಾನತೆಯನ್ನು ಹೊಂದಿರದ ಕೆಲವು PHP ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿರದ ಹೊರತು PHP ಕೋಡ್ ಅನ್ನು ಯಾವಾಗಲೂ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದು.

PHP 8.0 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾದ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಬಹುಶಃ ಹೀಗಿರಬಹುದು:

#[SomeAttr]
function someFunc() {}

#[AnotherAttr]
class SomeClass {}

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

ಅಭಿವೃದ್ಧಿ ಬಳಕೆಗಾಗಿ ಉದ್ದೇಶಿಸಲಾದ ಗುಣಲಕ್ಷಣಗಳು, ಉದಾಹರಣೆಗೆ #[Deprecated], ಯೂನಿಯನ್ ಪ್ರಕಾರಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ರೀತಿಯಲ್ಲಿಯೇ ತೆಗೆದುಹಾಕಬಹುದು. ಆದರೆ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಡವಳಿಕೆಯನ್ನು ಮಾರ್ಪಡಿಸುವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳನ್ನು ನೇರವಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ.

ಇಂದಿನಿಂದ, ಯಾವುದೇ ಟ್ರಾನ್ಸ್‌ಪೈಲರ್ PHP 8.0 ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಅದರ ಸಮಾನವಾದ PHP 7.4 ಕೋಡ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಉತ್ಪಾದಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ನಿಮ್ಮ PHP ಕೋಡ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬಳಸಬೇಕಾದರೆ, ಅದನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವುದು ಕಷ್ಟ ಅಥವಾ ಕಾರ್ಯಸಾಧ್ಯವಲ್ಲ.

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದಾದ PHP ವೈಶಿಷ್ಟ್ಯಗಳು

ಇವುಗಳು PHP 7.1 ಮತ್ತು ಅದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪ್ರಸ್ತುತ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದಾಗಿದೆ. ನಿಮ್ಮ ಕೋಡ್ ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಮಾತ್ರ ಬಳಸಿದರೆ, ನಿಮ್ಮ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ಖಚಿತತೆಯನ್ನು ನೀವು ಆನಂದಿಸಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಕೋಡ್ ವೈಫಲ್ಯಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆಯೇ ಎಂದು ನೀವು ನಿರ್ಣಯಿಸಬೇಕಾಗುತ್ತದೆ.

ಪಿಎಚ್ಪಿ ಆವೃತ್ತಿವೈಶಿಷ್ಟ್ಯಗಳು
7.1ಎಲ್ಲವೂ
7.2- object ಮಾದರಿ
- ಪ್ಯಾರಾಮೀಟರ್ ಪ್ರಕಾರದ ವಿಸ್ತರಣೆ
- PREG_UNMATCHED_AS_NULL ಧ್ವಜದಲ್ಲಿ preg_match
7.3- ರಲ್ಲಿ ಉಲ್ಲೇಖ ಕಾರ್ಯಯೋಜನೆಗಳು list() / ಅರೇ ಡಿಸ್ಟ್ರಕ್ಚರಿಂಗ್ (ಒಳಗೆ ಹೊರತುಪಡಿಸಿ foreach - #4376)
- ಹೊಂದಿಕೊಳ್ಳುವ ಹೆರೆಡಾಕ್ ಮತ್ತು ನೌಡಾಕ್ ಸಿಂಟ್ಯಾಕ್ಸ್
- ಫಂಕ್ಷನ್‌ಗಳ ಕರೆಗಳಲ್ಲಿ ಅಲ್ಪವಿರಾಮಗಳನ್ನು ಹಿಂದುಳಿದಿದೆ
- set(raw)cookie $option ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ
7.4- ಟೈಪ್ ಮಾಡಿದ ಗುಣಲಕ್ಷಣಗಳು
- ಬಾಣದ ಕಾರ್ಯಗಳು
- ಶೂನ್ಯ ಒಟ್ಟುಗೂಡಿಸುವ ನಿಯೋಜನೆ ಆಪರೇಟರ್
- ರಚನೆಗಳ ಒಳಗೆ ಅನ್ಪ್ಯಾಕ್ ಮಾಡಲಾಗುತ್ತಿದೆ
- ಸಂಖ್ಯಾತ್ಮಕ ಅಕ್ಷರಶಃ ವಿಭಜಕ
- strip_tags() ಟ್ಯಾಗ್ ಹೆಸರುಗಳ ಶ್ರೇಣಿಯೊಂದಿಗೆ
- ಕೋವೇರಿಯಂಟ್ ರಿಟರ್ನ್ ವಿಧಗಳು ಮತ್ತು ಕಾಂಟ್ರಾವೇರಿಯಂಟ್ ಪ್ಯಾರಮ್ ಪ್ರಕಾರಗಳು
8.0- ಯೂನಿಯನ್ ವಿಧಗಳು
- mixed ಹುಸಿ ಪ್ರಕಾರ
- static ರಿಟರ್ನ್ ಪ್ರಕಾರ
- ::class ವಸ್ತುಗಳ ಮೇಲೆ ಮ್ಯಾಜಿಕ್ ಸ್ಥಿರ
- match ಅಭಿವ್ಯಕ್ತಿಗಳು
- catch ವಿನಾಯಿತಿಗಳು ಪ್ರಕಾರದಿಂದ ಮಾತ್ರ
- ಶೂನ್ಯ-ಸುರಕ್ಷಿತ ಆಪರೇಟರ್
- ವರ್ಗ ನಿರ್ಮಾಣಕಾರ ಆಸ್ತಿ ಪ್ರಚಾರ
- ಪ್ಯಾರಾಮೀಟರ್ ಪಟ್ಟಿಗಳಲ್ಲಿ ಅಲ್ಪವಿರಾಮಗಳನ್ನು ಹಿಂದುಳಿದಿದೆ ಮತ್ತು ಮುಚ್ಚುವಿಕೆ use ಪಟ್ಟಿಗಳನ್ನು

PHP ಟ್ರಾನ್ಸ್‌ಪೈಲರ್‌ಗಳು

ಪ್ರಸ್ತುತ, PHP ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ಒಂದು ಸಾಧನವಿದೆ: ರೆಕ್ಟರ್.

ರೆಕ್ಟರ್ ಒಂದು PHP ಪುನರ್ನಿರ್ಮಾಣ ಸಾಧನವಾಗಿದೆ, ಇದು ಪ್ರೋಗ್ರಾಮೆಬಲ್ ನಿಯಮಗಳ ಆಧಾರದ ಮೇಲೆ PHP ಕೋಡ್ ಅನ್ನು ಪರಿವರ್ತಿಸುತ್ತದೆ. ನಾವು ಮೂಲ ಕೋಡ್ ಮತ್ತು ರನ್ ಮಾಡಲು ನಿಯಮಗಳ ಸೆಟ್ ಅನ್ನು ಇನ್ಪುಟ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ರೆಕ್ಟರ್ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುತ್ತಾರೆ.

ರೆಕ್ಟರ್ ಅನ್ನು ಆಜ್ಞಾ ಸಾಲಿನ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ, ಸಂಯೋಜಕ ಮೂಲಕ ಯೋಜನೆಯಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ರೆಕ್ಟರ್ ಪರಿವರ್ತನೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ ಕೋಡ್‌ನ "ವ್ಯತ್ಯಾಸ" (ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ ಸೇರ್ಪಡೆಗಳು, ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿ ತೆಗೆಯುವಿಕೆಗಳು) ಅನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡುತ್ತದೆ:

ರೆಕ್ಟರ್‌ನಿಂದ "ಡಿಫ್" ಔಟ್‌ಪುಟ್
ರೆಕ್ಟರ್‌ನಿಂದ "ಡಿಫ್" ಔಟ್‌ಪುಟ್

PHP ಯ ಯಾವ ಆವೃತ್ತಿಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬೇಕು

PHP ಆವೃತ್ತಿಗಳಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು, ಅನುಗುಣವಾದ ನಿಯಮಗಳನ್ನು ರಚಿಸಬೇಕು.

ಇಂದು, ರೆಕ್ಟರ್ ಲೈಬ್ರರಿಯು PHP 8.0 ರಿಂದ 7.1 ರ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡಲು ಹೆಚ್ಚಿನ ನಿಯಮಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ನಮ್ಮ PHP ಕೋಡ್ ಅನ್ನು ಆವೃತ್ತಿ 7.1 ರವರೆಗೂ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದು.

PHP 7.1 ರಿಂದ 7.0 ಮತ್ತು 7.0 ರಿಂದ 5.6 ರವರೆಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ನಿಯಮಗಳಿವೆ, ಆದರೆ ಇವುಗಳು ಸಮಗ್ರವಾಗಿಲ್ಲ. ಅವುಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ, ಆದ್ದರಿಂದ ನಾವು ಅಂತಿಮವಾಗಿ PHP ಕೋಡ್ ಅನ್ನು ಆವೃತ್ತಿ 5.6 ಗೆ ವರ್ಗಾಯಿಸಬಹುದು.

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ vs ಬ್ಯಾಕ್‌ಪೋರ್ಟಿಂಗ್

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

ಉದಾಹರಣೆಗೆ, ಕಾರ್ಯ str_contains PHP 8.0 ರಲ್ಲಿ ಪರಿಚಯಿಸಲಾಯಿತು. PHP 7.4 ಮತ್ತು ಕೆಳಗಿನ ಅದೇ ಕಾರ್ಯವನ್ನು ಈ ರೀತಿ ಸುಲಭವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು:

if (!defined('PHP_VERSION_ID') || (defined('PHP_VERSION_ID') && PHP_VERSION_ID < 80000)) {
  if (!function_exists('str_contains')) {
    /**
     * Checks if a string contains another
     *
     * @param string $haystack The string to search in
     * @param string $needle The string to search
     * @return boolean Returns TRUE if the needle was found in haystack, FALSE otherwise.
     */
    function str_contains(string $haystack, string $needle): bool
    {
      return strpos($haystack, $needle) !== false;
    }
  }
}

ಬ್ಯಾಕ್‌ಪೋರ್ಟಿಂಗ್ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್‌ಗಿಂತ ಸರಳವಾಗಿರುವುದರಿಂದ, ಬ್ಯಾಕ್‌ಪೋರ್ಟಿಂಗ್ ಕೆಲಸವನ್ನು ಮಾಡಿದಾಗಲೆಲ್ಲಾ ನಾವು ಈ ಪರಿಹಾರವನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕು.

PHP 8.0 ರಿಂದ 7.1 ರ ನಡುವಿನ ವ್ಯಾಪ್ತಿಯ ಬಗ್ಗೆ, ನಾವು Symfony ನ ಪಾಲಿಫಿಲ್ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಬಹುದು:

  • ಪಾಲಿಫಿಲ್ PHP 7.1
  • ಪಾಲಿಫಿಲ್ PHP 7.2
  • ಪಾಲಿಫಿಲ್ PHP 7.3
  • ಪಾಲಿಫಿಲ್ PHP 7.4
  • ಪಾಲಿಫಿಲ್ PHP 8.0

ಈ ಗ್ರಂಥಾಲಯಗಳು ಈ ಕೆಳಗಿನ ಕಾರ್ಯಗಳು, ತರಗತಿಗಳು, ಸ್ಥಿರಾಂಕಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಬ್ಯಾಕ್‌ಪೋರ್ಟ್ ಮಾಡುತ್ತವೆ:

ಪಿಎಚ್ಪಿ ಆವೃತ್ತಿವೈಶಿಷ್ಟ್ಯಗಳು
7.2ಕಾರ್ಯಗಳು:

  • spl_object_id
  • utf8_encode
  • utf8_decode

ಸ್ಥಿರಾಂಕಗಳು:

  • PHP_FLOAT_*
  • PHP_OS_FAMILY
7.3ಕಾರ್ಯಗಳು:

  • array_key_first
  • array_key_last
  • hrtime
  • is_countable

ವಿನಾಯಿತಿಗಳು:

  • JsonException
7.4ಕಾರ್ಯಗಳು:

  • get_mangled_object_vars
  • mb_str_split
  • password_algos
8.0ಇಂಟರ್ಫೇಸ್ಗಳು:

  • Stringable

ತರಗತಿಗಳು:

  • ValueError
  • UnhandledMatchError

ಸ್ಥಿರಾಂಕಗಳು:

  • FILTER_VALIDATE_BOOL

ಕಾರ್ಯಗಳು:

  • fdiv
  • get_debug_type
  • preg_last_error_msg
  • str_contains
  • str_starts_with
  • str_ends_with
  • get_resource_id

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ PHP ಯ ಉದಾಹರಣೆಗಳು

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲಾದ PHP ಕೋಡ್‌ನ ಕೆಲವು ಉದಾಹರಣೆಗಳನ್ನು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಆಗುತ್ತಿರುವ ಕೆಲವು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸೋಣ.

PHP ಕೋಡ್

ದಿ match ಅಭಿವ್ಯಕ್ತಿಯನ್ನು PHP 8.0 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾಯಿತು. ಈ ಮೂಲ ಕೋಡ್:

function getFieldValue(string $fieldName): ?string
{
  return match($fieldName) {
    'foo' => 'foofoo',
    'bar' => 'barbar',
    'baz' => 'bazbaz',
    default => null,
  };
}

…ಅದನ್ನು ಬಳಸಿಕೊಂಡು ಅದರ ಸಮಾನವಾದ PHP 7.4 ಆವೃತ್ತಿಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ switch ಆಪರೇಟರ್:

function getFieldValue(string $fieldName): ?string
{
  switch ($fieldName) {
    case 'foo':
      return 'foofoo';
    case 'bar':
      return 'barbar';
    case 'baz':
      return 'bazbaz';
    default:
      return null;
  }
}

nullsafe ಆಪರೇಟರ್ ಅನ್ನು PHP 8.0 ನಲ್ಲಿ ಸಹ ಪರಿಚಯಿಸಲಾಯಿತು:

public function getValue(TypeResolverInterface $typeResolver): ?string
{
  return $this->getResolver($typeResolver)?->getValue();
}

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲಾದ ಕೋಡ್ ಕಾರ್ಯಾಚರಣೆಯ ಮೌಲ್ಯವನ್ನು ಮೊದಲು ಹೊಸ ವೇರಿಯೇಬಲ್‌ಗೆ ನಿಯೋಜಿಸುವ ಅಗತ್ಯವಿದೆ, ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಎರಡು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು:

public function getValue(TypeResolverInterface $typeResolver): ?string
{
  return ($val = $this->getResolver($typeResolver)) ? $val->getValue() : null;
}

PHP 8.0 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾದ ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್ ಪ್ರಾಪರ್ಟಿ ಪ್ರಚಾರದ ವೈಶಿಷ್ಟ್ಯವು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಕಡಿಮೆ ಕೋಡ್ ಬರೆಯಲು ಅನುಮತಿಸುತ್ತದೆ:

class QueryResolver
{
  function __construct(protected QueryFormatter $queryFormatter)
  {
  }
}

PHP 7.4 ಗಾಗಿ ಅದನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವಾಗ, ಕೋಡ್‌ನ ಸಂಪೂರ್ಣ ತುಣುಕು ಉತ್ಪತ್ತಿಯಾಗುತ್ತದೆ:

 class QueryResolver
 {
  protected QueryFormatter $queryFormatter;

  function __construct(QueryFormatter $queryFormatter)
  {
    $this->queryFormatter = $queryFormatter;
  }
}

ಮೇಲಿನ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್ ಟೈಪ್ ಮಾಡಲಾದ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ, ಇದನ್ನು PHP 7.4 ನಲ್ಲಿ ಪರಿಚಯಿಸಲಾಗಿದೆ. ಆ ಕೋಡ್ ಅನ್ನು PHP 7.3 ಗೆ ವರ್ಗಾಯಿಸುವುದು ಅವುಗಳನ್ನು ಡಾಕ್‌ಬ್ಲಾಕ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ:

 class QueryResolver
 {
  /**
   * @var QueryFormatter
   */
  protected $queryFormatter;

  function __construct(QueryFormatter $queryFormatter)
  {
    $this->queryFormatter = $queryFormatter;
  }
}

PHP ಪ್ಯಾಕೇಜುಗಳು

ಕೆಳಗಿನ ಲೈಬ್ರರಿಗಳನ್ನು ಉತ್ಪಾದನೆಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತಿದೆ:

ಗ್ರಂಥಾಲಯ/ವಿವರಣೆಕೋಡ್/ಟಿಪ್ಪಣಿಗಳು
ರೆಕ್ಟರ್
PHP ಪುನರ್ನಿರ್ಮಾಣ ಸಾಧನವು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಅನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ
- ಮೂಲ ಕೋಡ್
– ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್
- ಟಿಪ್ಪಣಿಗಳು
ಸುಲಭ ಕೋಡಿಂಗ್ ಮಾನದಂಡಗಳು
PHP ಕೋಡ್ ಹೊಂದಲು ಉಪಕರಣವು ನಿಯಮಗಳ ಗುಂಪಿಗೆ ಬದ್ಧವಾಗಿದೆ
- ಮೂಲ ಕೋಡ್
– ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್
- ಟಿಪ್ಪಣಿಗಳು
WordPress ಗಾಗಿ GraphQL API
ಪ್ಲಗಿನ್ WordPress ಗಾಗಿ GraphQL ಸರ್ವರ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ
- ಮೂಲ ಕೋಡ್
– ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್
- ಟಿಪ್ಪಣಿಗಳು

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡುವ ಒಳಿತು ಮತ್ತು ಕೆಡುಕುಗಳು

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

ಇದು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಮಗೆ ಉತ್ತಮ ಡೆವಲಪರ್‌ಗಳಾಗಲು ಅನುಮತಿಸುತ್ತದೆ, ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಏಕೆಂದರೆ ನಮ್ಮ ಮೂಲ ಕೋಡ್ PHP 8.0 ನ ಯೂನಿಯನ್ ಪ್ರಕಾರಗಳು, PHP 7.4 ನ ಟೈಪ್ ಮಾಡಿದ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು PHP ಯ ಪ್ರತಿ ಹೊಸ ಆವೃತ್ತಿಗೆ ಸೇರಿಸಲಾದ ವಿವಿಧ ಪ್ರಕಾರಗಳು ಮತ್ತು ಹುಸಿ ಪ್ರಕಾರಗಳನ್ನು ಬಳಸಬಹುದು (mixed PHP 8.0 ನಿಂದ, object PHP 7.2 ರಿಂದ), PHP ಯ ಇತರ ಆಧುನಿಕ ವೈಶಿಷ್ಟ್ಯಗಳ ನಡುವೆ.

ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ನಾವು ದೋಷಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಹಿಡಿಯಬಹುದು ಮತ್ತು ಓದಲು ಸುಲಭವಾದ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬಹುದು.

ಈಗ, ನ್ಯೂನತೆಗಳನ್ನು ನೋಡೋಣ.

ಇದನ್ನು ಕೋಡ್ ಮಾಡಬೇಕು ಮತ್ತು ನಿರ್ವಹಿಸಬೇಕು

ರೆಕ್ಟರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬಹುದು, ಆದರೆ ಪ್ರಕ್ರಿಯೆಯು ನಮ್ಮ ನಿರ್ದಿಷ್ಟ ಸೆಟಪ್‌ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕೆಲವು ಹಸ್ತಚಾಲಿತ ಇನ್‌ಪುಟ್ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಥರ್ಡ್-ಪಾರ್ಟಿ ಲೈಬ್ರರಿಗಳನ್ನು ಸಹ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬೇಕು

ಸಂಭವನೀಯ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಅವರ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾದ ಕಾರಣ ಅವುಗಳನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವಾಗ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡಿದಾಗ ಇದು ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ. ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದಾದರೆ ಮತ್ತು ಯೋಜನೆಯು ತೆರೆದ ಮೂಲವಾಗಿದ್ದರೆ, ನಾವು ಪುಲ್ ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಬೇಕಾಗುತ್ತದೆ. ಲೈಬ್ರರಿ ಓಪನ್ ಸೋರ್ಸ್ ಇಲ್ಲದಿದ್ದರೆ, ನಾವು ರಸ್ತೆ ತಡೆಯನ್ನು ಹೊಡೆಯಬಹುದು.

ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ರೆಕ್ಟರ್ ನಮಗೆ ತಿಳಿಸುವುದಿಲ್ಲ

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

ಡೀಬಗ್ ಮಾಡುವ ಮಾಹಿತಿಯು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಮೂಲ ಕೋಡ್ ಅಲ್ಲ

ಅಪ್ಲಿಕೇಶನ್ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಸ್ಟಾಕ್ ಟ್ರೇಸ್‌ನೊಂದಿಗೆ ದೋಷ ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸಿದಾಗ, ಸಾಲಿನ ಸಂಖ್ಯೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಕೋಡ್‌ಗೆ ಸೂಚಿಸುತ್ತದೆ. ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ಅನುಗುಣವಾದ ಸಾಲಿನ ಸಂಖ್ಯೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್‌ನಿಂದ ಮೂಲ ಕೋಡ್‌ಗೆ ಹಿಂತಿರುಗಿಸಬೇಕಾಗಿದೆ.

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್ ಕೂಡ ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿರಬೇಕು

ನಮ್ಮ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಪ್ರಾಜೆಕ್ಟ್ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಇತರ ಕೆಲವು ಲೈಬ್ರರಿಗಳು ಅದೇ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅವಲಂಬನೆಯನ್ನು ಬಳಸಬಹುದು. ಈ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಅವಲಂಬನೆಯನ್ನು ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಇತರ ಲೈಬ್ರರಿಗೆ ಅದರ ಮೂಲ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಇರಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಸಂಭಾವ್ಯ ಘರ್ಷಣೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಆವೃತ್ತಿಯನ್ನು PHP-Scoper, Strauss ಅಥವಾ ಇತರ ಕೆಲವು ಸಾಧನಗಳ ಮೂಲಕ ಪೂರ್ವಪ್ರತ್ಯಯ ಮಾಡಬೇಕು.

ನಿರಂತರ ಏಕೀಕರಣ (CI) ಸಮಯದಲ್ಲಿ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ನಡೆಯಬೇಕು

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲಾದ ಕೋಡ್ ಸ್ವಾಭಾವಿಕವಾಗಿ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸುತ್ತದೆ ಏಕೆಂದರೆ, ನಾವು ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರನ್ ಮಾಡಬಾರದು ಅಥವಾ ನಾವು ಅಡ್ಡ ಪರಿಣಾಮಗಳನ್ನು ಸೃಷ್ಟಿಸುವ ಅಪಾಯವನ್ನು ಎದುರಿಸುತ್ತೇವೆ. CI ರನ್ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ರನ್ ಮಾಡುವುದು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ (ಇದರ ಬಗ್ಗೆ ಕೆಳಗೆ ಹೆಚ್ಚು).

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವುದು ಹೇಗೆ

ಮೊದಲಿಗೆ, ಅಭಿವೃದ್ಧಿಗಾಗಿ ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ರೆಕ್ಟರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬೇಕಾಗಿದೆ:

composer require rector/rector --dev

ನಂತರ ನಾವು ಎ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ rector.php ಅಗತ್ಯವಿರುವ ನಿಯಮಗಳ ಸೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಯೋಜನೆಯ ಮೂಲ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್. PHP 8.0 ನಿಂದ 7.1 ಗೆ ಕೋಡ್ ಅನ್ನು ಡೌನ್‌ಗ್ರೇಡ್ ಮಾಡಲು, ನಾವು ಈ ಸಂರಚನೆಯನ್ನು ಬಳಸುತ್ತೇವೆ:

use RectorSetValueObjectDowngradeSetList;
use SymfonyComponentDependencyInjectionLoaderConfiguratorContainerConfigurator;

return static function (ContainerConfigurator $containerConfigurator): void {
    $containerConfigurator->import(DowngradeSetList::PHP_80);
    $containerConfigurator->import(DowngradeSetList::PHP_74);
    $containerConfigurator->import(DowngradeSetList::PHP_73);
    $containerConfigurator->import(DowngradeSetList::PHP_72);
};

ಪ್ರಕ್ರಿಯೆಯು ನಿರೀಕ್ಷೆಯಂತೆ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು ರೆಕ್ಟರ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು process ಡ್ರೈ ಮೋಡ್‌ನಲ್ಲಿ ಆದೇಶ, ಪ್ರಕ್ರಿಯೆಗೆ ಸ್ಥಳ(ಗಳನ್ನು) ರವಾನಿಸುವುದು (ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಫೋಲ್ಡರ್‌ನ ಅಡಿಯಲ್ಲಿ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳು src/):

vendor/bin/rector process src --dry-run

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡಲು, ನಾವು ರೆಕ್ಟರ್ಸ್ ಅನ್ನು ನಡೆಸುತ್ತೇವೆ process ಆಜ್ಞೆ, ಇದು ಫೈಲ್‌ಗಳನ್ನು ಅವುಗಳ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸ್ಥಳದಲ್ಲಿ ಮಾರ್ಪಡಿಸುತ್ತದೆ:

vendor/bin/rector process src

ದಯವಿಟ್ಟು ಗಮನಿಸಿ: ನಾವು ಓಡಿದರೆ rector process ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ, ಮೂಲ ಕೋಡ್ ಅನ್ನು ಸ್ಥಳದಲ್ಲಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ src/. ಆದಾಗ್ಯೂ, ಕೋಡ್ ಅನ್ನು ಡೌನ್‌ಗ್ರೇಡ್ ಮಾಡುವಾಗ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸದಿರಲು ನಾವು ಪರಿವರ್ತಿಸಲಾದ ಕೋಡ್ ಅನ್ನು ಬೇರೆ ಸ್ಥಳದಲ್ಲಿ ಉತ್ಪಾದಿಸಲು ಬಯಸುತ್ತೇವೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ನಿರಂತರ ಏಕೀಕರಣದ ಸಮಯದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಡೆಸುವುದು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ.

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುವುದು

ಉತ್ಪಾದನೆಗಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಡೆಲಿವರಿಯನ್ನು ಉತ್ಪಾದಿಸಲು, ಉತ್ಪಾದನೆಯ ಕೋಡ್ ಅನ್ನು ಮಾತ್ರ ಪರಿವರ್ತಿಸಬೇಕು; ಅಭಿವೃದ್ಧಿಗೆ ಮಾತ್ರ ಅಗತ್ಯವಿರುವ ಕೋಡ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಇದರರ್ಥ ನಾವು ಎಲ್ಲಾ ಪರೀಕ್ಷೆಗಳನ್ನು (ನಮ್ಮ ಯೋಜನೆ ಮತ್ತು ಅದರ ಅವಲಂಬನೆಗಳೆರಡಕ್ಕೂ) ಮತ್ತು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಬಹುದು.

ಪರೀಕ್ಷೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಎಲ್ಲಿವೆ ಎಂದು ನಾವು ಈಗಾಗಲೇ ತಿಳಿದಿರುತ್ತೇವೆ - ಉದಾಹರಣೆಗೆ, ಫೋಲ್ಡರ್ ಅಡಿಯಲ್ಲಿ tests/. ಅವಲಂಬನೆಗಳು ಎಲ್ಲಿವೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿಯಬೇಕು - ಉದಾಹರಣೆಗೆ, ಅವುಗಳ ಉಪ ಫೋಲ್ಡರ್‌ಗಳ ಅಡಿಯಲ್ಲಿ tests/, test/ ಮತ್ತು Test/ (ವಿವಿಧ ಗ್ರಂಥಾಲಯಗಳಿಗೆ). ನಂತರ, ಈ ಫೋಲ್ಡರ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದನ್ನು ಬಿಟ್ಟುಬಿಡಲು ನಾವು ರೆಕ್ಟರ್‌ಗೆ ಹೇಳುತ್ತೇವೆ:

return static function (ContainerConfigurator $containerConfigurator): void {
  // ...

  $parameters->set(Option::SKIP, [
    // Skip tests
    '*/tests/*',
    '*/test/*',
    '*/Test/*',
  ]);
};

ಅವಲಂಬನೆಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಸಂಯೋಜಕರಿಗೆ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಯಾವುದು (ಪ್ರವೇಶದ ಅಡಿಯಲ್ಲಿದೆ require-dev in composer.json) ಮತ್ತು ಉತ್ಪಾದನೆಗೆ ಯಾವುದು (ಪ್ರವೇಶದಲ್ಲಿರುವವು require).

ಉತ್ಪಾದನೆಗಾಗಿ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳ ಮಾರ್ಗಗಳನ್ನು ಸಂಯೋಜಕರಿಂದ ಹಿಂಪಡೆಯಲು, ನಾವು ನಡೆಸುತ್ತೇವೆ:

composer info --path --no-dev

ಈ ಆಜ್ಞೆಯು ಅವುಗಳ ಹೆಸರು ಮತ್ತು ಮಾರ್ಗದೊಂದಿಗೆ ಅವಲಂಬನೆಗಳ ಪಟ್ಟಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಈ ರೀತಿ:

brain/cortex                     /Users/leo/GitHub/leoloso/PoP/vendor/brain/cortex
composer/installers              /Users/leo/GitHub/leoloso/PoP/vendor/composer/installers
composer/semver                  /Users/leo/GitHub/leoloso/PoP/vendor/composer/semver
guzzlehttp/guzzle                /Users/leo/GitHub/leoloso/PoP/vendor/guzzlehttp/guzzle
league/pipeline                  /Users/leo/GitHub/leoloso/PoP/vendor/league/pipeline

ನಾವು ಎಲ್ಲಾ ಮಾರ್ಗಗಳನ್ನು ಹೊರತೆಗೆಯಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ರೆಕ್ಟರ್ ಆಜ್ಞೆಗೆ ಫೀಡ್ ಮಾಡಬಹುದು, ಅದು ನಮ್ಮ ಯೋಜನೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ src/ ಫೋಲ್ಡರ್ ಜೊತೆಗೆ ಉತ್ಪಾದನೆಗೆ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿರುವ ಫೋಲ್ಡರ್‌ಗಳು:

$ paths="$(composer info --path --no-dev | cut -d' ' -f2- | sed 's/ //g' | tr 'n' ' ')"
$ vendor/bin/rector process src $paths

ಮತ್ತಷ್ಟು ಸುಧಾರಣೆಯು ಈಗಾಗಲೇ ಗುರಿ PHP ಆವೃತ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಆ ಅವಲಂಬನೆಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ರೆಕ್ಟರ್ ಅನ್ನು ತಡೆಯಬಹುದು. ಲೈಬ್ರರಿಯನ್ನು PHP 7.1 (ಅಥವಾ ಕೆಳಗಿನ ಯಾವುದೇ ಆವೃತ್ತಿ) ನೊಂದಿಗೆ ಕೋಡ್ ಮಾಡಿದ್ದರೆ, ಅದನ್ನು PHP 7.1 ಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.

ಇದನ್ನು ಸಾಧಿಸಲು, ನಾವು PHP 7.2 ಮತ್ತು ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿರುವ ಲೈಬ್ರರಿಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಮಾತ್ರ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ನಾವು ಈ ಎಲ್ಲಾ ಗ್ರಂಥಾಲಯಗಳ ಹೆಸರುಗಳನ್ನು ಸಂಯೋಜಕರ ಮೂಲಕ ಪಡೆಯುತ್ತೇವೆ why-not ಆಜ್ಞೆ, ಈ ರೀತಿಯಾಗಿ:

composer why-not php "7.1.*" | grep -o "S*/S*"

ಏಕೆಂದರೆ ಈ ಆಜ್ಞೆಯು ಇದರೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ --no-dev ಫ್ಲ್ಯಾಗ್, ಉತ್ಪಾದನೆಗೆ ಮಾತ್ರ ಅವಲಂಬನೆಗಳನ್ನು ಸೇರಿಸಲು, ನಾವು ಮೊದಲು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಅವಲಂಬನೆಗಳನ್ನು ತೆಗೆದುಹಾಕಬೇಕು ಮತ್ತು ಆಟೋಲೋಡರ್ ಅನ್ನು ಪುನರುತ್ಪಾದಿಸಬೇಕು, ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಮತ್ತೆ ಸೇರಿಸಬೇಕು:

$ composer install --no-dev
$ packages=$(composer why-not php "7.1.*" | grep -o "S*/S*")
$ composer install

ಸಂಯೋಜಕರ info --path ಆಜ್ಞೆಯು ಈ ಸ್ವರೂಪದೊಂದಿಗೆ ಪ್ಯಾಕೇಜ್‌ಗಾಗಿ ಮಾರ್ಗವನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ:

# Executing this command
$ composer info psr/cache --path   
# Produces this response:
psr/cache /Users/leo/GitHub/leoloso/PoP/vendor/psr/cache

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ಎಲ್ಲಾ ಮಾರ್ಗಗಳನ್ನು ಪಡೆಯಲು ನಮ್ಮ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಐಟಂಗಳಿಗೆ ನಾವು ಈ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ:

ನಿಮಗೆ ಸ್ಪರ್ಧಾತ್ಮಕ ಅಂಚನ್ನು ನೀಡುವ ಹೋಸ್ಟಿಂಗ್ ಪರಿಹಾರ ಬೇಕೇ? Behmasterನೀವು ನಂಬಲಾಗದ ವೇಗ, ಅತ್ಯಾಧುನಿಕ ಭದ್ರತೆ ಮತ್ತು ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್‌ನಿಂದ ಆವರಿಸಲ್ಪಟ್ಟಿದ್ದೀರಿ. ನಮ್ಮ ಯೋಜನೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

for package in $packages
do
  path=$(composer info $package --path | cut -d' ' -f2-)
  paths="$paths $path"
done

ಅಂತಿಮವಾಗಿ, ನಾವು ಈ ಪಟ್ಟಿಯನ್ನು ರೆಕ್ಟರ್‌ಗೆ ಒದಗಿಸುತ್ತೇವೆ (ಜೊತೆಗೆ ಯೋಜನೆಯ src/ ಫೋಲ್ಡರ್):

vendor/bin/rector process src $paths

ಕೋಡ್ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವಾಗ ತಪ್ಪಿಸಬೇಕಾದ ಮೋಸಗಳು

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಕೋಡ್ ಅನ್ನು ಕಲೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದು, ಆಗಾಗ್ಗೆ ಯೋಜನೆಗೆ ನಿರ್ದಿಷ್ಟವಾದ ಟ್ವೀಕ್‌ಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ. ನಾವು ಎದುರಿಸಬಹುದಾದ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡೋಣ.

ಚೈನ್ಡ್ ನಿಯಮಗಳನ್ನು ಯಾವಾಗಲೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ

ಒಂದು ನಿಯಮವು ಹಿಂದಿನ ನಿಯಮದಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಕೋಡ್ ಅನ್ನು ಪರಿವರ್ತಿಸಬೇಕಾದಾಗ ಚೈನ್ಡ್ ರೂಲ್ ಆಗಿದೆ.

ಉದಾಹರಣೆಗೆ, ಗ್ರಂಥಾಲಯ symfony/cache ಈ ಕೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ:

final class CacheItem implements ItemInterface
{
  public function tag($tags): ItemInterface
  {
    // ...
    return $this;
  }
}

PHP 7.4 ರಿಂದ 7.3 ಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವಾಗ, ಕಾರ್ಯ tag ಎರಡು ಮಾರ್ಪಾಡುಗಳಿಗೆ ಒಳಗಾಗಬೇಕು:

  • ಹಿಂತಿರುಗಿಸುವ ಪ್ರಕಾರ ItemInterface ಗೆ ಮೊದಲು ಪರಿವರ್ತಿಸಬೇಕು self, ನಿಯಮದ ಕಾರಣದಿಂದಾಗಿ DowngradeCovariantReturnTypeRector
  • ಹಿಂತಿರುಗಿಸುವ ಪ್ರಕಾರ self ನಂತರ ನಿಯಮದ ಕಾರಣದಿಂದ ತೆಗೆದುಹಾಕಬೇಕು DowngradeSelfTypeDeclarationRector

ಅಂತಿಮ ಫಲಿತಾಂಶವು ಹೀಗಿರಬೇಕು:

final class CacheItem implements ItemInterface
{
  public function tag($tags)
  {
    // ...
    return $this;
  }
}

ಆದಾಗ್ಯೂ, ರೆಕ್ಟರ್ ಮಧ್ಯಂತರ ಹಂತವನ್ನು ಮಾತ್ರ ನೀಡುತ್ತದೆ:

final class CacheItem implements ItemInterface
{
  public function tag($tags): self
  {
    // ...
    return $this;
  }
}

ಸಮಸ್ಯೆಯೆಂದರೆ, ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುವ ಕ್ರಮವನ್ನು ರೆಕ್ಟರ್ ಯಾವಾಗಲೂ ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಯಾವ ಚೈನ್ಡ್ ನಿಯಮಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದೆ ಬಿಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗುರುತಿಸುವುದು ಮತ್ತು ಅವುಗಳನ್ನು ಅನ್ವಯಿಸಲು ಹೊಸ ರೆಕ್ಟರ್ ರನ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಪರಿಹಾರವಾಗಿದೆ.

ಚೈನ್ಡ್ ನಿಯಮಗಳನ್ನು ಗುರುತಿಸಲು, ನಾವು ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ಎರಡು ಬಾರಿ ರೆಕ್ಟರ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ, ಈ ರೀತಿ:

$ vendor/bin/rector process src
$ vendor/bin/rector process src --dry-run

ಮೊದಲ ಬಾರಿಗೆ, ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ನಿರೀಕ್ಷೆಯಂತೆ ರೆಕ್ಟರ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ. ಎರಡನೇ ಬಾರಿಗೆ ನಾವು ಬಳಸುತ್ತೇವೆ --dry-run ಇನ್ನೂ ಮಾಡಬೇಕಾದ ಬದಲಾವಣೆಗಳಿವೆಯೇ ಎಂದು ಕಂಡುಹಿಡಿಯಲು ಫ್ಲ್ಯಾಗ್. ಇದ್ದರೆ, ಆಜ್ಞೆಯು ದೋಷ ಕೋಡ್‌ನೊಂದಿಗೆ ನಿರ್ಗಮಿಸುತ್ತದೆ ಮತ್ತು "diff" ಔಟ್‌ಪುಟ್ ಯಾವ ನಿಯಮವನ್ನು (ಗಳನ್ನು) ಇನ್ನೂ ಅನ್ವಯಿಸಬಹುದು ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕೆಲವು ಚೈನ್ಡ್ ನಿಯಮವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದಿರುವ ಮೂಲಕ ಮೊದಲ ರನ್ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ ಎಂದು ಅರ್ಥ.

--ಡ್ರೈ-ರನ್ ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ರೆಕ್ಟರ್ ರನ್ನಿಂಗ್
-ಡ್ರೈ-ರನ್ ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ರೆಕ್ಟರ್ ರನ್ನಿಂಗ್

ಒಮ್ಮೆ ನಾವು ಅನ್ವಯಿಸದ ಚೈನ್ಡ್ ನಿಯಮವನ್ನು (ಅಥವಾ ನಿಯಮಗಳು) ಗುರುತಿಸಿದ ನಂತರ, ನಾವು ಇನ್ನೊಂದು ರೆಕ್ಟರ್ ಕಾನ್ಫಿಗರ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸಬಹುದು - ಉದಾಹರಣೆಗೆ, rector-chained-rule.php ಕಾಣೆಯಾದ ನಿಯಮವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಅಡಿಯಲ್ಲಿ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ ನಿಯಮಗಳ ಸೆಟ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಬದಲು src/, ಈ ಸಮಯದಲ್ಲಿ, ನಿರ್ದಿಷ್ಟ ಫೈಲ್ ಅನ್ನು ಅನ್ವಯಿಸಬೇಕಾದ ನಿರ್ದಿಷ್ಟ ತಪ್ಪಿದ ನಿಯಮವನ್ನು ನಾವು ಚಲಾಯಿಸಬಹುದು:

// rector-chained-rule.php
use RectorCoreConfigurationOption;
use RectorDowngradePhp74RectorClassMethodDowngradeSelfTypeDeclarationRector;
use SymfonyComponentDependencyInjectionLoaderConfiguratorContainerConfigurator;

return static function (ContainerConfigurator $containerConfigurator): void {
  $services = $containerConfigurator->services();
  $services->set(DowngradeSelfTypeDeclarationRector::class);

  $parameters = $containerConfigurator->parameters();
  $parameters->set(Option::PATHS, [
    __DIR__ . '/vendor/symfony/cache/CacheItem.php',
  ]);
};

ಅಂತಿಮವಾಗಿ, ಇನ್‌ಪುಟ್ ಮೂಲಕ ಹೊಸ ಕಾನ್ಫಿಗರ್ ಫೈಲ್ ಅನ್ನು ಬಳಸಲು ನಾವು ರೆಕ್ಟರ್‌ಗೆ ಅದರ ಎರಡನೇ ಪಾಸ್‌ನಲ್ಲಿ ಹೇಳುತ್ತೇವೆ --config:

# First pass with all modifications
$ vendor/bin/rector process src

# Second pass to fix a specific problem
$ vendor/bin/rector process --config=rector-chained-rule.php

ಸಂಯೋಜಕ ಅವಲಂಬನೆಗಳು ಅಸಮಂಜಸವಾಗಿರಬಹುದು

ಗ್ರಂಥಾಲಯಗಳು ಅಭಿವೃದ್ಧಿಗಾಗಿ ಅವಲಂಬನೆಯನ್ನು ಘೋಷಿಸಬಹುದು (ಅಂದರೆ ಅಡಿಯಲ್ಲಿ require-dev in composer.json), ಆದರೂ, ಉತ್ಪಾದನೆಗಾಗಿ ಅವುಗಳಿಂದ ಕೆಲವು ಕೋಡ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿ (ಕೆಳಗಿನ ಕೆಲವು ಫೈಲ್‌ಗಳಂತಹವು src/, ಅಲ್ಲ tests/).

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

ಉದಾಹರಣೆಗೆ, ವರ್ಗ EarlyExpirationHandler ಸಿಮ್ಫೋನಿಯ ಕ್ಯಾಶ್ ಕಾಂಪೊನೆಂಟ್ ಇಂಪ್ಲಿಮೆಂಟ್ಸ್ ಇಂಟರ್ಫೇಸ್ ನಿಂದ MessageHandlerInterface ಮೆಸೆಂಜರ್ ಘಟಕದಿಂದ:

class EarlyExpirationHandler implements MessageHandlerInterface
{
    //...
}

ಆದಾಗ್ಯೂ, symfony/cache ಘೋಷಿಸಿತು symfony/messenger ಅಭಿವೃದ್ಧಿಗೆ ಅವಲಂಬನೆಯಾಗಬೇಕು. ನಂತರ, ಅವಲಂಬಿಸಿರುವ ಯೋಜನೆಯಲ್ಲಿ ರೆಕ್ಟರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗ symfony/cache, ಇದು ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ:

[ERROR] Could not process "vendor/symfony/cache/Messenger/EarlyExpirationHandler.php" file, due to:             
  "Analyze error: "Class SymfonyComponentMessengerHandlerMessageHandlerInterface not found.". Include your files in "$parameters->set(Option::AUTOLOAD_PATHS, [...]);" in "rector.php" config.
  See https://github.com/rectorphp/rector#configuration".   

ಈ ಸಮಸ್ಯೆಗೆ ಮೂರು ಪರಿಹಾರಗಳಿವೆ:

  1. ರೆಕ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ, ಆ ಕೋಡ್‌ನ ತುಣುಕನ್ನು ಉಲ್ಲೇಖಿಸುವ ಫೈಲ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದನ್ನು ಬಿಟ್ಟುಬಿಡಿ:
return static function (ContainerConfigurator $containerConfigurator): void {
  // ...

  $parameters->set(Option::SKIP, [
    __DIR__ . '/vendor/symfony/cache/Messenger/EarlyExpirationHandler.php',
  ]);
};
  1. ಕಾಣೆಯಾದ ಲೈಬ್ರರಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ರೆಕ್ಟರ್ ಮೂಲಕ ಸ್ವಯಂ ಲೋಡ್ ಮಾಡಲು ಅದರ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ:
return static function (ContainerConfigurator $containerConfigurator): void {
  // ...

  $parameters->set(Option::AUTOLOAD_PATHS, [
    __DIR__ . '/vendor/symfony/messenger',
  ]);
};
  1. ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಉತ್ಪಾದನೆಗಾಗಿ ಕಾಣೆಯಾದ ಲೈಬ್ರರಿಯನ್ನು ಅವಲಂಬಿಸಿರಲಿ:
composer require symfony/messenger

ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮತ್ತು ನಿರಂತರ ಏಕೀಕರಣ

ಮೊದಲೇ ಹೇಳಿದಂತೆ, ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ನಾವು ಬಳಸಬೇಕು --dry-run ರೆಕ್ಟರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗ ಫ್ಲ್ಯಾಗ್ ಮಾಡಿ ಅಥವಾ ಇಲ್ಲದಿದ್ದರೆ, ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಕೋಡ್‌ನೊಂದಿಗೆ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅತಿಕ್ರಮಿಸಲಾಗುತ್ತದೆ. ಈ ಕಾರಣಕ್ಕಾಗಿ, ನಿರಂತರ ಏಕೀಕರಣದ (CI) ಸಮಯದಲ್ಲಿ ನಿಜವಾದ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಚಲಾಯಿಸಲು ಇದು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿದೆ, ಅಲ್ಲಿ ನಾವು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ತಾತ್ಕಾಲಿಕ ಓಟಗಾರರನ್ನು ಸ್ಪಿನ್ ಮಾಡಬಹುದು.

ನಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ಗಾಗಿ ಬಿಡುಗಡೆಯನ್ನು ರಚಿಸುವಾಗ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸೂಕ್ತ ಸಮಯ. ಉದಾಹರಣೆಗೆ, ಕೆಳಗಿನ ಕೋಡ್ GitHub ಕ್ರಿಯೆಗಳಿಗಾಗಿ ವರ್ಕ್‌ಫ್ಲೋ ಆಗಿದೆ, ಇದು WordPress ಪ್ಲಗಿನ್‌ನ ಬಿಡುಗಡೆಯನ್ನು ರಚಿಸುತ್ತದೆ:

name: Generate Installable Plugin and Upload as Release Asset
on:
  release:
    types: [published]
jobs:
  build:
    name: Build, Downgrade and Upload Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Downgrade code for production (to PHP 7.1)
        run: |
          composer install
          vendor/bin/rector process
          sed -i 's/Requires PHP: 7.4/Requires PHP: 7.1/' graphql-api.php
      - name: Build project for production
        run: |
          composer install --no-dev --optimize-autoloader
          mkdir build
      - name: Create artifact
        uses: montudor/action-zip@v0.1.0
        with:
          args: zip -X -r build/graphql-api.zip . -x *.git* node_modules/* .* "*/.*" CODE_OF_CONDUCT.md CONTRIBUTING.md ISSUE_TEMPLATE.md PULL_REQUEST_TEMPLATE.md rector.php *.dist composer.* dev-helpers** build**
      - name: Upload artifact
        uses: actions/upload-artifact@v2
        with:
            name: graphql-api
            path: build/graphql-api.zip
      - name: Upload to release
        uses: JasonEtco/upload-to-release@master
        with:
          args: build/graphql-api.zip application/zip
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GitHub ಕ್ರಿಯೆಗಳ ಮೂಲಕ ವರ್ಡ್ಪ್ರೆಸ್ ಪ್ಲಗಿನ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಈ ವರ್ಕ್‌ಫ್ಲೋ ಪ್ರಮಾಣಿತ ವಿಧಾನವನ್ನು ಒಳಗೊಂಡಿದೆ. ಹೊಸ ಸೇರ್ಪಡೆ, ಪ್ಲಗಿನ್‌ನ ಕೋಡ್ ಅನ್ನು PHP 7.4 ರಿಂದ 7.1 ಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು, ಈ ಹಂತದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ:

      - name: Downgrade code for production (to PHP 7.1)
        run: |
          vendor/bin/rector process
          sed -i 's/Requires PHP: 7.4/Requires PHP: 7.1/' graphql-api.php

ಒಟ್ಟಿಗೆ ತೆಗೆದುಕೊಂಡರೆ, ಈ ಕೆಲಸದ ಹರಿವು ಈಗ ಈ ಕೆಳಗಿನ ಹಂತಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:

  1. PHP 7.4 ನೊಂದಿಗೆ ಬರೆಯಲಾದ ಅದರ ರೆಪೊಸಿಟರಿಯಿಂದ WordPress ಪ್ಲಗಿನ್‌ಗಾಗಿ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ
  2. ಅದರ ಸಂಯೋಜಕ ಅವಲಂಬನೆಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ
  3. ಅದರ ಕೋಡ್ ಅನ್ನು PHP 7.4 ರಿಂದ 7.1 ಕ್ಕೆ ವರ್ಗಾಯಿಸುತ್ತದೆ
  4. ಪ್ಲಗಿನ್‌ನ ಮುಖ್ಯ ಫೈಲ್‌ನ ಹೆಡರ್‌ನಲ್ಲಿ "PHP ಅಗತ್ಯವಿದೆ" ನಮೂದನ್ನು ಮಾರ್ಪಡಿಸುತ್ತದೆ "7.4" ಗೆ "7.1"
  5. ಅಭಿವೃದ್ಧಿಗೆ ಅಗತ್ಯವಿರುವ ಅವಲಂಬನೆಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ
  6. ಎಲ್ಲಾ ಅನಗತ್ಯ ಫೈಲ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಪ್ಲಗಿನ್‌ನ .zip ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ
  7. .zip ಫೈಲ್ ಅನ್ನು ಬಿಡುಗಡೆಯ ಆಸ್ತಿಯಾಗಿ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ (ಮತ್ತು, ಹೆಚ್ಚುವರಿಯಾಗಿ, GitHub ಕ್ರಿಯೆಗೆ ಕಲಾಕೃತಿಯಾಗಿ)

ಟ್ರಾನ್ಸ್‌ಪೈಲ್ಡ್ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ

ಕೋಡ್ ಅನ್ನು PHP 7.1 ಗೆ ವರ್ಗಾಯಿಸಿದ ನಂತರ, ಅದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ? ಅಥವಾ, ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿವರ್ತಿಸಲಾಗಿದೆ ಮತ್ತು PHP ಕೋಡ್‌ನ ಹೆಚ್ಚಿನ ಆವೃತ್ತಿಗಳ ಯಾವುದೇ ಅವಶೇಷಗಳು ಉಳಿದಿಲ್ಲ ಎಂದು ನಮಗೆ ಹೇಗೆ ಗೊತ್ತು?

ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವಂತೆಯೇ, ನಾವು CI ಪ್ರಕ್ರಿಯೆಯೊಳಗೆ ಪರಿಹಾರವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಓಟಗಾರನ ಪರಿಸರವನ್ನು PHP 7.1 ನೊಂದಿಗೆ ಹೊಂದಿಸುವುದು ಮತ್ತು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಕೋಡ್‌ನಲ್ಲಿ ಒಂದು ಲಿಂಟರ್ ಅನ್ನು ರನ್ ಮಾಡುವುದು ಕಲ್ಪನೆಯಾಗಿದೆ. ಯಾವುದೇ ಕೋಡ್ ತುಣುಕು PHP 7.1 ರೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ (ಅಂದರೆ PHP 7.4 ನಿಂದ ಟೈಪ್ ಮಾಡಿದ ಆಸ್ತಿಯನ್ನು ಪರಿವರ್ತಿಸಲಾಗಿಲ್ಲ), ನಂತರ ಲಿಂಟರ್ ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ.

PHP ಗಾಗಿ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುವ ಲಿಂಟರ್ PHP ಪ್ಯಾರಲಲ್ ಲಿಂಟ್ ಆಗಿದೆ. ನಾವು ಈ ಲೈಬ್ರರಿಯನ್ನು ನಮ್ಮ ಯೋಜನೆಯಲ್ಲಿ ಅಭಿವೃದ್ಧಿಗೆ ಅವಲಂಬನೆಯಾಗಿ ಸ್ಥಾಪಿಸಬಹುದು ಅಥವಾ CI ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವತಂತ್ರ ಸಂಯೋಜಕ ಯೋಜನೆಯಾಗಿ ಸ್ಥಾಪಿಸಬಹುದು:

composer create-project php-parallel-lint/php-parallel-lint

ಕೋಡ್ PHP 7.2 ಮತ್ತು ಹೆಚ್ಚಿನದನ್ನು ಹೊಂದಿರುವಾಗ, PHP ಪ್ಯಾರಲಲ್ ಲಿಂಟ್ ಈ ರೀತಿಯ ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ:

Run php-parallel-lint/parallel-lint layers/ vendor/ --exclude vendor/symfony/polyfill-ctype/bootstrap80.php --exclude vendor/symfony/polyfill-intl-grapheme/bootstrap80.php --exclude vendor/symfony/polyfill-intl-idn/bootstrap80.php --exclude vendor/symfony/polyfill-intl-normalizer/bootstrap80.php --exclude vendor/symfony/polyfill-mbstring/bootstrap80.php
PHP 7.1.33 | 10 parallel jobs
............................................................   60/2870 (2 %)
............................................................  120/2870 (4 %)
...
............................................................  660/2870 (22 %)
.............X..............................................  720/2870 (25 %)
............................................................  780/2870 (27 %)
...
............................................................ 2820/2870 (98 %)
..................................................           2870/2870 (100 %)


Checked 2870 files in 15.4 seconds
Syntax error found in 1 file

------------------------------------------------------------
Parse error: layers/GraphQLAPIForWP/plugins/graphql-api-for-wp/graphql-api.php:55
    53|     '0.8.0',
    54|     __('GraphQL API for WordPress', 'graphql-api'),
  > 55| ))) {
    56|     $plugin->setup();
    57| }
Unexpected ')' in layers/GraphQLAPIForWP/plugins/graphql-api-for-wp/graphql-api.php on line 55
Error: Process completed with exit code 1.

ನಮ್ಮ CI ನ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಲಿಂಟರ್ ಅನ್ನು ಸೇರಿಸೋಣ. PHP 8.0 ರಿಂದ 7.1 ಗೆ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಹಂತಗಳು:

  1. ಮೂಲ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ
  2. ಪರಿಸರವು PHP 8.0 ಅನ್ನು ರನ್ ಮಾಡಿ, ಆದ್ದರಿಂದ ರೆಕ್ಟರ್ ಮೂಲ ಕೋಡ್ ಅನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳಬಹುದು
  3. PHP 7.1 ಗೆ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿ
  4. PHP ಲಿಂಟರ್ ಉಪಕರಣವನ್ನು ಸ್ಥಾಪಿಸಿ
  5. ಪರಿಸರದ PHP ಆವೃತ್ತಿಯನ್ನು 7.1 ಗೆ ಬದಲಿಸಿ
  6. ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಿದ ಕೋಡ್‌ನಲ್ಲಿ ಲಿಂಟರ್ ಅನ್ನು ರನ್ ಮಾಡಿ

ಈ GitHub ಆಕ್ಷನ್ ವರ್ಕ್‌ಫ್ಲೋ ಕೆಲಸ ಮಾಡುತ್ತದೆ:

name: Downgrade PHP tests
jobs:
  main:
    name: Downgrade code to PHP 7.1 via Rector, and execute tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set-up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.0
          coverage: none

      - name: Local packages - Downgrade PHP code via Rector
        run: |
          composer install
          vendor/bin/rector process

      # Prepare for testing on PHP 7.1
      - name: Install PHP Parallel Lint
        run: composer create-project php-parallel-lint/php-parallel-lint --ansi

      - name: Switch to PHP 7.1
        uses: shivammathur/setup-php@v2
        with:
          php-version: 7.1
          coverage: none

      # Lint the transpiled code
      - name: Run PHP Parallel Lint on PHP 7.1
        run: php-parallel-lint/parallel-lint src/ vendor/ --exclude vendor/symfony/polyfill-ctype/bootstrap80.php --exclude vendor/symfony/polyfill-intl-grapheme/bootstrap80.php --exclude vendor/symfony/polyfill-intl-idn/bootstrap80.php --exclude vendor/symfony/polyfill-intl-normalizer/bootstrap80.php --exclude vendor/symfony/polyfill-mbstring/bootstrap80.php

ಹಲವಾರು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ bootstrap80.php ಸಿಮ್ಫೋನಿಯ ಪಾಲಿಫಿಲ್ ಲೈಬ್ರರಿಗಳಿಂದ ಫೈಲ್‌ಗಳನ್ನು (ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ) ಲಿಂಟರ್‌ನಿಂದ ಹೊರಗಿಡಬೇಕು. ಈ ಫೈಲ್‌ಗಳು PHP 8.0 ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ಲಿಂಟರ್ ದೋಷಗಳನ್ನು ಎಸೆಯುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಈ ಫೈಲ್‌ಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಸುರಕ್ಷಿತವಾಗಿದೆ ಏಕೆಂದರೆ ಅವುಗಳು PHP 8.0 ಅಥವಾ ಹೆಚ್ಚಿನದನ್ನು ಚಾಲನೆ ಮಾಡುವಾಗ ಮಾತ್ರ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಲೋಡ್ ಆಗುತ್ತವೆ:

if (PHP_VERSION_ID >= 80000) {
  return require __DIR__.'/bootstrap80.php';
}

ನೀವು WordPress ಗಾಗಿ ಸಾರ್ವಜನಿಕ ಪ್ಲಗಿನ್ ಅನ್ನು ರಚಿಸುತ್ತಿರಲಿ ಅಥವಾ ನೀವು ಲೆಗಸಿ ಕೋಡ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತಿರಲಿ, ಇತ್ತೀಚಿನ PHP ಆವೃತ್ತಿಯನ್ನು ಬಳಸುವುದು ಅಸಾಧ್ಯವಾಗಲು ಹಲವು ಕಾರಣಗಳಿವೆ 👩‍💻 ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ 👇ಟ್ವೀಟ್ ಮಾಡಲು ಕ್ಲಿಕ್ ಮಾಡಿ

ಸಾರಾಂಶ

ಈ ಲೇಖನವು ನಮ್ಮ PHP ಕೋಡ್ ಅನ್ನು ಹೇಗೆ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡಬೇಕೆಂದು ನಮಗೆ ಕಲಿಸಿದೆ, ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ PHP 8.0 ಅನ್ನು ಬಳಸಲು ಮತ್ತು PHP 7.1 ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬಿಡುಗಡೆಯನ್ನು ರಚಿಸಲು ನಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. PHP ಪುನರ್ನಿರ್ಮಾಣ ಸಾಧನವಾದ ರೆಕ್ಟರ್ ಮೂಲಕ ಟ್ರಾನ್ಸ್‌ಪೈಲಿಂಗ್ ಮಾಡಲಾಗುತ್ತದೆ.

ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವುದರಿಂದ ನಮ್ಮನ್ನು ಉತ್ತಮ ಡೆವಲಪರ್‌ಗಳನ್ನಾಗಿ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ನಾವು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ದೋಷಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಹಿಡಿಯಬಹುದು ಮತ್ತು ಸ್ವಾಭಾವಿಕವಾಗಿ ಓದಲು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ ಕೋಡ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಹುದು.

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

PHP ಅನ್ನು ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುವ ಕುರಿತು ನಿಮ್ಮಲ್ಲಿ ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳು ಉಳಿದಿವೆಯೇ? ಕಾಮೆಂಟ್ಗಳ ವಿಭಾಗದಲ್ಲಿ ನಮಗೆ ತಿಳಿಸಿ!

ಸಂಬಂಧಿತ ಲೇಖನಗಳು

0 ಪ್ರತಿಕ್ರಿಯೆಗಳು
ಇನ್ಲೈನ್ ​​ಪ್ರತಿಕ್ರಿಯೆಗಳು
ಎಲ್ಲಾ ಕಾಮೆಂಟ್‌ಗಳನ್ನು ವೀಕ್ಷಿಸಿ
ಮೇಲಿನ ಬಟನ್ಗೆ ಹಿಂತಿರುಗಿ